From michaelc@IDSSOFTWARE.COM Wed Nov 2 07:46:20 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 71A8721F8BC3 for ; Wed, 2 Nov 2011 07:46:20 -0700 (PDT) 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 ydRuO0wVIiPs for ; Wed, 2 Nov 2011 07:46:20 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id E4E5F21F8A7D for ; Wed, 2 Nov 2011 07:46:19 -0700 (PDT) Received: (qmail 6077 invoked from network); 2 Nov 2011 14:46:18 -0000 Received: from unknown (HELO localhost) (10.6.230.45) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 2 Nov 2011 14:46:18 -0000 Received: (qmail 5149 invoked by uid 0); 2 Nov 2011 14:46:18 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.6.03 Message-Id: <20111102045006.61e8c06078a3b23a733c71e914c0b9df.93281283c9.wbe@email03.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Wed, 02 Nov 2011 07:25:00 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Overlap of RTO and ORT 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, 02 Nov 2011 14:46:20 -0000 Hi,=0A=0ASay the newly coined "overlay-reliability-timer" (ORT) in base-19 = has a=0A3 second default.=0A=0ABase-19 section 5.6.3.1 paragraph 6 describe= s an example of a 500ms RTO=0Aand re)transmission at 0ms, 500ms, 1500ms, 35= 00ms, 7500ms. One problem=0Awith this paragraph is that it is mixing recei= ving ACK with receiving a=0Aresponse of a request, which are two distinct s= teps. The second problem=0Ais obvious, the 4th transmission at 3.5 second = overlaps the first ORT.=0A=0AThe second paragraph of this section also says= , "A node MUST NOT have=0Amore than one unacknowledged message on the DTLS = connection at a time." =0AThis means RTO trumps ORT such that if a request = originator has not=0Areceived an ACK from its first hop peer, ORT must not = fire or must start=0Aafter ACK from the first hop is received. This does n= ot apply to=0Aintermediate peers.=0A=0AIf this is by design, then it is too= important not to spell it out in=0Athe draft. I will come up with some tex= t if everybody agrees on "RTO=0Atrumps ORT" or "ORT starts after ACK" for r= equest originator.=0A=0AThanks=0A=0A--Michael=0A From petithug@acm.org Sat Nov 5 09:52:14 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 89D1C21F851F for ; Sat, 5 Nov 2011 09:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.671 X-Spam-Level: X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 9rX-w4oxG95j for ; Sat, 5 Nov 2011 09:52:13 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 8360821F8515 for ; Sat, 5 Nov 2011 09:52:13 -0700 (PDT) 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 14EA3200D1 for ; Sat, 5 Nov 2011 16:43:08 +0000 (UTC) Message-ID: <4EB569B9.7000501@acm.org> Date: Sat, 05 Nov 2011 09:52:09 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: p2psip@ietf.org References: <20111031155148.3443.27139.idtracker@ietfa.amsl.com> In-Reply-To: <20111031155148.3443.27139.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] I-D Action: draft-ietf-p2psip-concepts-04.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: Sat, 05 Nov 2011 16:52:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following comments and nits from my previous review are still pending: 1. Section 3, second paragraph. To improve the reading flow of section 3 as a whole, I would suggest to replace the first sentence by this: "A P2PSIP Overlay consists of one or more nodes called Peers and may also include Clients." 2. Section 3.5 OPEN ISSUE I would suggest to move this whole section into a "Design Notes" appendix at the end of the document. See also comment 10. 3. Section 4, 2rd paragraph "SIP Redirector" I would suggest to use "SIP Redirect Server" instead, as defined in RFC 3261 Section 6. 6. Section 5: Responsible Peer I did not read all the literature on the subject, but I never saw the term "Root Peer" used as synonym for "Responsible Peer." 7. Section 6.4, second paragraph: "The P2PSIP WG..." Replace by "This document..." 8. Section 6.4, third paragraph This paragraph talks about "multicast-bootstrap", but it should also talk about unicast bootstrap (or s/multicast-bootstrap/bootstrap/) 9. Security Section Security section missing. 10. Section 7 Open Issues As an implementer that is constantly confronted to interoperability issues, I think that preserving the reasons why decisions were made is really important and should be part of each RFC as an appendix. This would prevent a lot of guessing when future implementers who never participate in the discussion will start working on this. Nits ==== - - Abstract s/mechansims/mechanisms/ An abstract should not contain references. - - Section 1. s/eselection/selection/ - - Section 3. "Session Initiation Protocol (SIP)" is already defined in Section 2, so using only "SIP" is OK. - - Section 6.1 s/resource-id/Resource-ID/ s/resource record/Resource Record/ - - Section 6.2 s/resource record/Resource Record/ On 10/31/2011 08:51 AM, internet-drafts@ietf.org wrote: > 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 : Concepts and Terminology for Peer to Peer SIP > Author(s) : David A. Bryan > Philip Matthews > Eunsoo Shim > Dean Willis > Spencer Dawkins > Filename : draft-ietf-p2psip-concepts-04.txt > Pages : 20 > Date : 2011-10-31 > > This document defines concepts and terminology for the use of the > Session Initiation Protocol in a peer-to-peer environment where the > traditional proxy-registrar and message routing functions are > replaced by a distributed mechanism. These mechansims may be > implemented using a distributed hash table or other distributed data > mechanism with similar external properties. This document includes a > high-level view of the functional relationships between the network > elements defined herein, a conceptual model of operations, and an > outline of the related problems addressed by the P2PSIP working group > and the RELOAD protocol ([I-D.ietf-p2psip-base], > [I-D.ietf-p2psip-sip]) defined by the working group. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-p2psip-concepts-04.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-concepts-04.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) iEYEARECAAYFAk61abcACgkQ9RoMZyVa61fkxQCfanyJGPehH0EwAebx7HAe8XOz SCYAn3hRJrTs5dAcBPn5hvVSsQXwSk8h =SdOp -----END PGP SIGNATURE----- From petithug@acm.org Sat Nov 5 11:40:32 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 D5A1A21F85D1 for ; Sat, 5 Nov 2011 11:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 0t8Opj7mj5cd for ; Sat, 5 Nov 2011 11:40:32 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 2057E21F85A4 for ; Sat, 5 Nov 2011 11:40:32 -0700 (PDT) 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 A860A200D1 for ; Sat, 5 Nov 2011 18:31:27 +0000 (UTC) Message-ID: <4EB5831C.3070808@acm.org> Date: Sat, 05 Nov 2011 11:40:28 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Review of draft-ietf-p2psip-service-discovery-03 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: Sat, 05 Nov 2011 18:40:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Section 2 The Namespace definition uses "voice-mail" as an example of namespace, but nowhere in the spec it is defined if it is an ASCII string or a Unicode string and what encoding must be used when using it in RELOAD. 2. Section 4.1 The structure can be extended, but there is no type that can be used for that. Should we use the length? 3. Section 4.4 I do not understand why the refresh period had to be configured. Does it matter if different nodes use different lifetime duration for the entries they store? 4. Section 6. Shouldn't "service name" be replace by "namespace"? 5. Section 8 Probably a good idea to add the formal definition for the two elements, something like this (in Compact Relax NG Grammar): namespace redir = "urn:ietf:params:xml:ns:p2p:service-discovery" parameter &= element redir:branching-factor { xsd:unsignedInt } parameter &= element redir:refresh-period { xsd:unsignedInt } 6. Section 10 The XML namespace needs to be formally defined. Also it will probably be a good idea to define a IANA registry for the ReDir namespaces. Nits - ---- - - Section 1, 4th paragraph, and section 3, 1st paragraph s/fetch/Fetch/ - - Section 4.1 s/structure/Resource Record/ - - Section 4.6 s/redirServiceProvider/RedirServiceProvider/ s/"nonexistent"/exists=False/ - - Section 10.2 s/kind-ID/Kind-ID/ - -- 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) iEYEARECAAYFAk61gxoACgkQ9RoMZyVa61cpvgCgqqNh3BpTpmh5iMLeCixtIrEQ hFAAnAlb5xNh5NpN7FojrjbtkSWcszM+ =ouEE -----END PGP SIGNATURE----- From petithug@acm.org Sun Nov 6 08:29:40 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 D4EED21F84D4 for ; Sun, 6 Nov 2011 08:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.661 X-Spam-Level: X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 M6uVPLMdFdZb for ; Sun, 6 Nov 2011 08:29:40 -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 0856321F84CB for ; Sun, 6 Nov 2011 08:29:39 -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 7883A20138 for ; Sun, 6 Nov 2011 16:20:31 +0000 (UTC) Message-ID: <4EB6B5EE.4000309@acm.org> Date: Sun, 06 Nov 2011 08:29:34 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 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: Sun, 06 Nov 2011 16:29:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Section 5.1.1, structure definition The structure in the document is mangled, but should not this be better: enum { (2^16-1) } DiagnosticExtensionRequestType; struct { DiagnosticExtensionRequestType type; opaque diagnostic_extension_contents<0..2^32-1>; } DiagnosticExtension; // the ";" was missing struct { uint64 expiration; uint64 timestampInitiated; uint64 dMFlags; DiagnosticExtension diagnostic_extensions<0..2^32-1>; // the length is already here. } DiagnosticsRequest; Also the authors should choose between the CamelCase convention (timestampInitiated) or the underscore convention (diagnostic_extension_contents) but not mix the two. 2. Section 5.1.1, first and second field definitions This fields uses the NTP timestamp format, which is different from the format used by RELOAD (milliseconds since the epoch). Is there really a need for microseconds here? 3. Section 5.1.1, third field definition Is the request really allowed to set all dMFlags to '1', and so requesting diagnostics types that are not yet defined? 4. Section 5.1.3 I would add an additional diagnostic kind that provide the OS (or modify SOFTWARE_VERSION to provide the OS), for the purpose of evaluating if an overlay as enough OS diversity to handle a bug in a specific OS. 5. Section 5.1.3, MEMORY_FOOTPRINT A "kilo byte" of 1024 bytes is called kibibyte. 6. Section 5.3.1: structure definition The request type should be DiagnosticsRequest instead of DiagnosticRequest. 7. Section 5.4 This section should define the content of error_info for error codes 102 to 106 (probably UTF-8 text, but -base does not explicitly says what the default format is for error_info, so it need to be explicitly defined in each extension). For error code 101, why using a fixed-length text string, instead of a "opaque suberror<0..32>" 8. Section 8.1 This section should define the name of the new IANA registry 9. Section 8.2 This section should define the name of the new IANA registry Nits - ---- - - 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.3 s/New Reqeust/New Request/ - - Section 5.1.1, first paragraph s/Ping message or with/Ping message 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.11 (GNU/Linux) iEYEARECAAYFAk62tewACgkQ9RoMZyVa61e/3ACgqlLAmnDTLZGG78QU0kT8shzL p0kAnjEhQ741c+07Gn5gAhY6j4j+FtGY =i+f1 -----END PGP SIGNATURE----- From petithug@acm.org Sun Nov 6 08:40:39 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 BE67D21F8511 for ; Sun, 6 Nov 2011 08:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.657 X-Spam-Level: X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 hUYoeQQ+j4pE for ; Sun, 6 Nov 2011 08:40:39 -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 203E721F84FC for ; Sun, 6 Nov 2011 08:40:39 -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 5C33620138 for ; Sun, 6 Nov 2011 16:31:32 +0000 (UTC) Message-ID: <4EB6B884.6040008@acm.org> Date: Sun, 06 Nov 2011 08:40:36 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: P2PSIP Mailing List X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [P2PSIP] Review of draft-ietf-p2psip-ddr-00 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: Sun, 06 Nov 2011 16:40:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Section 6.2.2: second paragraph The new option is defined as EXTENSIVE_ROUTING_MODE_TYPE here and in other sections, but is define as extensive_routing_mode in the IANA registry in section 9.1. 2. Section 6.2.2, structure definition The enum does not follow the usual syntax: enum { (0), DDR(1), RPR(2), (255) } RouteMode; OverlayLink should be OverlayLinkType. In the next paragraph, Transport should be OverlayLinkType. - -- 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) iEYEARECAAYFAk62uH8ACgkQ9RoMZyVa61eugACgiMQucyky9UbXc4RWJbyf9tLR /ssAoKjYg/9a5WftuowTMImI/qF615KQ =61db -----END PGP SIGNATURE----- From bbl@lowekamp.net Sun Nov 6 21:25:45 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 7FC8E21F8A56 for ; Sun, 6 Nov 2011 21:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 W7Ek5OXYWXWJ for ; Sun, 6 Nov 2011 21:25:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1E7721F8A55 for ; Sun, 6 Nov 2011 21:25:44 -0800 (PST) Received: by iaeo4 with SMTP id o4so6947535iae.31 for ; Sun, 06 Nov 2011 21:25:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.202.17 with SMTP id fc17mr43468130icb.15.1320643543139; Sun, 06 Nov 2011 21:25:43 -0800 (PST) Received: by 10.42.180.3 with HTTP; Sun, 6 Nov 2011 21:25:42 -0800 (PST) In-Reply-To: <20111102045006.61e8c06078a3b23a733c71e914c0b9df.93281283c9.wbe@email03.secureserver.net> References: <20111102045006.61e8c06078a3b23a733c71e914c0b9df.93281283c9.wbe@email03.secureserver.net> Date: Mon, 7 Nov 2011 00:25:42 -0500 Message-ID: From: Bruce Lowekamp To: Michael Chen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Overlap of RTO and ORT 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: Mon, 07 Nov 2011 05:25:45 -0000 Michael, These timers exist at different layers and aren't really related. First, the overlay-reliability-timer was something that was added in response to some of the reviewers comments. (I know we had discussed the idea of making it configurable, and don't honestly recall what the reason was it wasn't made configurable earlier.) It was made an overlay parameter because it is also used to determine when intermediate peers can free state, which obviously shouldn't be before the requesting node times the transaction out. Regarding the retransmissions in 5.6.3.1, they are used both to provide semi-reliability and also to probe whether the link is functioning. As the goal of the Simple Reliabiity/Stop-and-wait protocol is to be as simple as possible, having a single retransmission timer that is also used to indicate link failure seems like the simplest solution. 5.6.3.1 also includes: If no ACKs have been received by the time the third retransmission occurs, it is RECOMMENDED that the link be removed from the routing table. This is only a recommendation to simplify the mandatory implementation, but the concept is the link can be removed more in a timeframe related to the ORT than to wait for a hard link failure. So in your particular scenario, what I think a good implementation should do is for the retransmission from the o-r-t to be sent over a different link in the routing table because the first link has been removed from the routing table even though retransmissions are still going on. Bruce On Wed, Nov 2, 2011 at 10:25 AM, Michael Chen wr= ote: > Hi, > > Say the newly coined "overlay-reliability-timer" (ORT) in base-19 has a > 3 second default. > > Base-19 section 5.6.3.1 paragraph 6 describes an example of a 500ms RTO > and re)transmission at 0ms, 500ms, 1500ms, 3500ms, 7500ms. =C2=A0One prob= lem > with this paragraph is that it is mixing receiving ACK with receiving a > response of a request, which are two distinct steps. =C2=A0The second pro= blem > is obvious, the 4th transmission at 3.5 second overlaps the first ORT. > > The second paragraph of this section also says, "A node MUST NOT have > more than one unacknowledged message on the DTLS connection at a time." > This means RTO trumps ORT such that if a request originator has not > received an ACK from its first hop peer, ORT must not fire or must start > after ACK from the first hop is received. =C2=A0This does not apply to > intermediate peers. > > If this is by design, then it is too important not to spell it out in > the draft. I will come up with some text if everybody agrees on "RTO > trumps ORT" or "ORT starts after ACK" for request originator. > > Thanks > > --Michael > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From zongning@huawei.com Sun Nov 6 21:39:31 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 9D37521F8490 for ; Sun, 6 Nov 2011 21:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.416 X-Spam-Level: X-Spam-Status: No, score=-105.416 tagged_above=-999 required=5 tests=[AWL=1.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 89gOfiUGitxx for ; Sun, 6 Nov 2011 21:39:30 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 11CDE21F84FB for ; Sun, 6 Nov 2011 21:39: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 <0LU900B8NZPI5P@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 07 Nov 2011 13:39:19 +0800 (CST) Received: from szxrg02-dlp.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 <0LU9009K5ZPIUS@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 07 Nov 2011 13:39:18 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEU31775; Mon, 07 Nov 2011 13:39:18 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 13:39:16 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.86]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 13:39:12 +0800 Date: Mon, 07 Nov 2011 05:38:54 +0000 From: ZongNing In-reply-to: <4EB6B884.6040008@acm.org> X-Originating-IP: [10.138.41.128] To: Marc Petit-Huguenin , P2PSIP Mailing List 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] Review of draft-ietf-p2psip-ddr-00 Thread-index: AQHMnKLWdhlwkkpRHkesFwYg+k5rTJWg5X9Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB6B884.6040008@acm.org> Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-ddr-00 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: Mon, 07 Nov 2011 05:39:31 -0000 Hi, Marc, Thank you for the review. I will submit a new revision after the IETF submission reopen. BR, Ning Zong -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin Sent: Monday, November 07, 2011 12:41 AM To: P2PSIP Mailing List Subject: [P2PSIP] Review of draft-ietf-p2psip-ddr-00 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Section 6.2.2: second paragraph The new option is defined as EXTENSIVE_ROUTING_MODE_TYPE here and in other sections, but is define as extensive_routing_mode in the IANA registry in section 9.1. 2. Section 6.2.2, structure definition The enum does not follow the usual syntax: enum { (0), DDR(1), RPR(2), (255) } RouteMode; OverlayLink should be OverlayLinkType. In the next paragraph, Transport should be OverlayLinkType. - -- 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) iEYEARECAAYFAk62uH8ACgkQ9RoMZyVa61eugACgiMQucyky9UbXc4RWJbyf9tLR /ssAoKjYg/9a5WftuowTMImI/qF615KQ =61db -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From jouni.maenpaa@ericsson.com Mon Nov 7 04:11:06 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 D591A21F8B49 for ; Mon, 7 Nov 2011 04:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Sdo6ydG1viM0 for ; Mon, 7 Nov 2011 04:11:06 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D908C21F8B3F for ; Mon, 7 Nov 2011 04:11:05 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-81-4eb7cad88c2c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B4.0C.13753.8DAC7BE4; Mon, 7 Nov 2011 13:11:05 +0100 (CET) Received: from ESESSCMS0364.eemea.ericsson.se ([169.254.1.77]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 7 Nov 2011 13:11:04 +0100 From: =?iso-8859-1?Q?Jouni_M=E4enp=E4=E4?= To: Marc Petit-Huguenin , P2PSIP Mailing List Date: Mon, 7 Nov 2011 13:11:03 +0100 Thread-Topic: [P2PSIP] Review of draft-ietf-p2psip-service-discovery-03 Thread-Index: Acyb6mgoB4/UnoZgRqqia8c+JlwsCgBW71PQ Message-ID: <2B0A8F5B80F8BA4A90AB906FF34A2EE7237C708751@ESESSCMS0364.eemea.ericsson.se> References: <4EB5831C.3070808@acm.org> In-Reply-To: <4EB5831C.3070808@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-service-discovery-03 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: Mon, 07 Nov 2011 12:11:06 -0000 Hi Marc, Thanks for the comments! We will address these in the next version of the d= raft. Regards, Jouni=20 -----Original Message----- From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of= Marc Petit-Huguenin Sent: 5. marraskuuta 2011 20:40 To: P2PSIP Mailing List Subject: [P2PSIP] Review of draft-ietf-p2psip-service-discovery-03 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. Section 2 The Namespace definition uses "voice-mail" as an example of namespace, but = nowhere in the spec it is defined if it is an ASCII string or a Unicode str= ing and what encoding must be used when using it in RELOAD. 2. Section 4.1 The structure can be extended, but there is no type that can be used for th= at. Should we use the length? 3. Section 4.4 I do not understand why the refresh period had to be configured. Does it m= atter if different nodes use different lifetime duration for the entries th= ey store? 4. Section 6. Shouldn't "service name" be replace by "namespace"? 5. Section 8 Probably a good idea to add the formal definition for the two elements, som= ething like this (in Compact Relax NG Grammar): namespace redir =3D "urn:ietf:params:xml:ns:p2p:service-discovery" parameter &=3D element redir:branching-factor { xsd:unsignedInt } parameter &=3D element redir:refresh-period { xsd:unsignedInt } 6. Section 10 The XML namespace needs to be formally defined. Also it will probably be a good idea to define a IANA registry for the ReDi= r namespaces. Nits - ---- - - Section 1, 4th paragraph, and section 3, 1st paragraph s/fetch/Fetch/ - - Section 4.1 s/structure/Resource Record/ - - Section 4.6 s/redirServiceProvider/RedirServiceProvider/ s/"nonexistent"/exists=3DFalse/ - - Section 10.2 s/kind-ID/Kind-ID/ - -- 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) iEYEARECAAYFAk61gxoACgkQ9RoMZyVa61cpvgCgqqNh3BpTpmh5iMLeCixtIrEQ hFAAnAlb5xNh5NpN7FojrjbtkSWcszM+ =3DouEE -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From haibin.song@huawei.com Thu Nov 10 23:12:04 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 390FF1F0C5F for ; Thu, 10 Nov 2011 23:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.797 X-Spam-Level: X-Spam-Status: No, score=-5.797 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 xsx7Fvu9nOpC for ; Thu, 10 Nov 2011 23:12:03 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8E1F0C35 for ; Thu, 10 Nov 2011 23:12:03 -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 <0LUH00K7QIM9ZI@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 11 Nov 2011 15:10:57 +0800 (CST) Received: from szxrg02-dlp.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 <0LUH002C3IM25Q@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 11 Nov 2011 15:10:57 +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 AEX75345; Fri, 11 Nov 2011 15:10:45 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 11 Nov 2011 15:10:36 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.229]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 11 Nov 2011 15:10:37 +0800 Date: Fri, 11 Nov 2011 07:03:48 +0000 From: Songhaibin In-reply-to: <4EB6B5EE.4000309@acm.org> X-Originating-IP: [10.138.41.129] To: Marc Petit-Huguenin , P2PSIP Mailing List 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] Review of draft-ietf-p2psip-diagnostics-06 Thread-index: AQHMnKFWx43ZR+qgE0y8OqUzpmrZnJWm+pRQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB6B5EE.4000309@acm.org> Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 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, 11 Nov 2011 07:12:04 -0000 Hi Marc, Thank you very much for the review. See reply in line. > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > Marc Petit-Huguenin > Sent: Monday, November 07, 2011 12:30 AM > To: P2PSIP Mailing List > Subject: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 1. Section 5.1.1, structure definition > > The structure in the document is mangled, but should not this be better: > Thank you for catching it. I will correct it. > enum { (2^16-1) } DiagnosticExtensionRequestType; > > struct { > DiagnosticExtensionRequestType type; > opaque diagnostic_extension_contents<0..2^32-1>; > } DiagnosticExtension; // the ";" was missing > OK. > struct { > uint64 expiration; > uint64 timestampInitiated; > uint64 dMFlags; > DiagnosticExtension diagnostic_extensions<0..2^32-1>; // the length is > already here. > } DiagnosticsRequest; struct { uint64 expiration; uint64 timestampInitiated; uint32 length; select (length) { case 0: uint64 dMFlags; case > 0: uint64 dMFlags; DiagnosticExtension diagnostic_extensions<0..2^32-1>; } } DiagnosticsRequest; By using structure, we mean that if the "length" field at the beginning of the request equals to "0", there is no other diagnostic information request except that contained in the dMFlags. If there are other extension types of diagnostic information are requested(as indicated by the length field), there will be DiagnosticEXtension field. But it seems there is something wrong here. Because in the draft it only allows at most 2^16 extension types, the diagnostic_extensions array should also be at most 2^16 long. Section 5.1.2 has the same problem. That is to say, "length" is the number of requested extension diagnostic types. > > Also the authors should choose between the CamelCase convention > (timestampInitiated) or the underscore convention > (diagnostic_extension_contents) but not mix the two. > That's to make it consistent with the base draft. For example, in the base draft section 5.3.3.1, the definition of ErrorResponse struct: public struct { uint16 error_code; opaque error_info<0..2^16-1>; } ErrorResponse; You see the structure name is in CamelCase, but the variable is in underscore convention. > > 2. Section 5.1.1, first and second field definitions > > This fields uses the NTP timestamp format, which is different from the format > used by RELOAD (milliseconds since the epoch). Is there really a need for > microseconds here? > If there is a consensus to use Unix time, the diagnostic draft will be updated to be consistent. > > 3. Section 5.1.1, third field definition > > Is the request really allowed to set all dMFlags to '1', and so requesting > diagnostics types that are not yet defined? > Only defined main diagnostics types are requested. From the extensibility consideration, it is good to classify the diagnostics types into two, one is the main types, the other is the extended types. We use 64 bits dMFlags to indicate the main diagnostics types that are requested. If there is requirement for more diagnostics types, they can define the extension types for use. The request will then contain the diagnostic_extensions<0..2^32-1> field as defined in section 5.1.1. > > 4. Section 5.1.3 > > I would add an additional diagnostic kind that provide the OS (or modify > SOFTWARE_VERSION to provide the OS), for the purpose of evaluating if an > overlay > as enough OS diversity to handle a bug in a specific OS. > To understand it deeply, could you give an example of what a bug it might be and how it will impact the overlay? > 5. Section 5.1.3, MEMORY_FOOTPRINT > > A "kilo byte" of 1024 bytes is called kibibyte. > That's really good. With "kibibyte" we do not need an extra explanation here:) > > 6. Section 5.3.1: structure definition > > The request type should be DiagnosticsRequest instead of DiagnosticRequest. > Good catch. > > 7. Section 5.4 > > This section should define the content of error_info for error codes 102 to 106 > (probably UTF-8 text, but -base does not explicitly says what the default format > is for error_info, so it need to be explicitly defined in each extension). > Good. They should be opaque text. > For error code 101, why using a fixed-length text string, instead of a "opaque > suberror<0..32>" > There are several types when error 101 was returned. We want to make it machine readable than just human readable, so as to classify them. > > 8. Section 8.1 > > This section should define the name of the new IANA registry > Yes. I will add it. > > 9. Section 8.2 > > This section should define the name of the new IANA registry > These Kind-IDs will be registered to the registry defined in Section 13.6 in the base draft. > > Nits > - ---- > > - - 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.3 > > s/New Reqeust/New Request/ > > - - Section 5.1.1, first paragraph > > s/Ping message or with/Ping message with/ > Thank you again, Marc. -Haibin > - -- > 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) > > iEYEARECAAYFAk62tewACgkQ9RoMZyVa61e/3ACgqlLAmnDTLZGG78QU0kT8shzL > p0kAnjEhQ741c+07Gn5gAhY6j4j+FtGY > =i+f1 > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Fri Nov 11 07:22: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 CB0C021F8880 for ; Fri, 11 Nov 2011 07:22:03 -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.343, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 Lb7szUKXXfsr for ; Fri, 11 Nov 2011 07:22:03 -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 E231021F85FF for ; Fri, 11 Nov 2011 07:22:02 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:ca0a:a9ff:fe2e:a4f6] (tem.shalmaneser.org [IPv6:2001:470:1f05:616:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id EAC912045B; Fri, 11 Nov 2011 15:12:33 +0000 (UTC) Message-ID: <4EBD3D91.4000803@acm.org> Date: Fri, 11 Nov 2011 10:21:53 -0500 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: Songhaibin References: <4EB6B5EE.4000309@acm.org> 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] Review of draft-ietf-p2psip-diagnostics-06 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, 11 Nov 2011 15:22:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inline. On 11/11/2011 02:03 AM, Songhaibin wrote: > Hi Marc, > > Thank you very much for the review. See reply in line. > >> -----Original Message----- From: p2psip-bounces@ietf.org >> [mailto:p2psip-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin Sent: >> Monday, November 07, 2011 12:30 AM To: P2PSIP Mailing List Subject: >> [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 [...] > > struct { uint64 expiration; uint64 timestampInitiated; uint64 dMFlags; > DiagnosticExtension diagnostic_extensions<0..2^32-1>; // the length is > already here. } DiagnosticsRequest; > >> struct { uint64 expiration; uint64 timestampInitiated; uint32 length; >> select (length) { case 0: uint64 dMFlags; case > 0: uint64 dMFlags; >> DiagnosticExtension diagnostic_extensions<0..2^32-1>; } } >> DiagnosticsRequest; > >> By using structure, we mean that if the "length" field at the beginning of >> the request equals to "0", there is no other diagnostic information request >> except that contained in the dMFlags. If there are other extension types of >> diagnostic information are requested(as indicated by the length field), >> there will be DiagnosticEXtension field. But it seems there is something >> wrong here. Because in the draft it only allows at most 2^16 extension >> types, the diagnostic_extensions array should also be at most 2^16 long. >> Section 5.1.2 has the same problem. What I meant is that the explicit length field and the implicit length field in the diagnostic_extensions field carry the same value, so why not eliminate one of them. > >> That is to say, "length" is the number of requested extension diagnostic >> types. Really? I would have thought that it was the size, not the number of instances. > > > Also the authors should choose between the CamelCase convention > (timestampInitiated) or the underscore convention > (diagnostic_extension_contents) but not mix the two. > > >> That's to make it consistent with the base draft. For example, in the base >> draft section 5.3.3.1, the definition of ErrorResponse struct: > >> public struct { uint16 error_code; opaque >> error_info<0..2^16-1>; } ErrorResponse; > >> You see the structure name is in CamelCase, but the variable is in >> underscore convention. Yes, but my point was that timestampInitiated is not consistent with either the base draft or the other fields in this draft. [...] > > 3. Section 5.1.1, third field definition > > Is the request really allowed to set all dMFlags to '1', and so requesting > diagnostics types that are not yet defined? > > >> Only defined main diagnostics types are requested. From the extensibility >> consideration, it is good to classify the diagnostics types into two, one >> is the main types, the other is the extended types. We use 64 bits dMFlags >> to indicate the main diagnostics types that are requested. If there is >> requirement for more diagnostics types, they can define the extension types >> for use. The request will then contain the diagnostic_extensions<0..2^32-1> >> field as defined in section 5.1.1. That's not what I meant. On the 64 main diagnostics types possibles, only 15 are defined. But the text says that all dMFlags must be set to '1', so it would request types that are not defined yet. Is it the intent? > > > 4. Section 5.1.3 > > I would add an additional diagnostic kind that provide the OS (or modify > SOFTWARE_VERSION to provide the OS), for the purpose of evaluating if an > overlay as enough OS diversity to handle a bug in a specific OS. > > >> To understand it deeply, could you give an example of what a bug it might >> be and how it will impact the overlay? It's about diversity in an overlay. If all the nodes are using the same RELOAD implementation, then the overlay will not survive a bug in this implementation. So a node can use diagnostics to evaluate the diversity in software implementations. Because OS have bugs too, OS diversity in an overlay is also a good thing, but diagnostics cannot be used for this purpose. Which bring another thing that is missing in diagnostics: The draft should define an XML namespace for the sole purpose of adding it to a element, to force all nodes of an overlay to support diagnostics. [...] > For error code 101, why using a fixed-length text string, instead of a > "opaque suberror<0..32>" > > >> There are several types when error 101 was returned. We want to make it >> machine readable than just human readable, so as to classify them. I think that a subcode + text with variable length is better than parsing an exact text, something like this: uint8 subcode; opaque reason<0..2^8-1> - -- 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) iEYEARECAAYFAk69PY4ACgkQ9RoMZyVa61eu4gCdEJkyC9YsRpCPutdBLlX6ayB5 xPMAn1PC0oNgCGt0w0ABMMpoMK8zNN9F =s463 -----END PGP SIGNATURE----- From petithug@acm.org Mon Nov 14 09:33:57 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 85D6011E8151 for ; Mon, 14 Nov 2011 09:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 w5vcYZK8uMCC for ; Mon, 14 Nov 2011 09:33: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 A8FD811E82E0 for ; Mon, 14 Nov 2011 09:33:52 -0800 (PST) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 2C5A820371; Mon, 14 Nov 2011 17:24:11 +0000 (UTC) Message-ID: <4EC150F9.8090109@acm.org> Date: Tue, 15 Nov 2011 01:33:45 +0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: Alexander Knauf References: <20111024171352.31303.35874.idtracker@ietfa.amsl.com> <4EA5A0E1.6070105@haw-hamburg.de> In-Reply-To: <4EA5A0E1.6070105@haw-hamburg.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: sam@irtf.org, P2PSIP Mailing List Subject: Re: [P2PSIP] Fwd: New Version Notification for draft-knauf-p2psip-share-02.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: Mon, 14 Nov 2011 17:33:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (CCed SAMRG mailing-list as this is where this draft will be presented - Unfortunately I will not be able to attend because of a conflict with VIPR) This version of the draft closes all my previous comments. I unfortunately did not had the time to finish my implementation of this in my RELOAD code and in Wireshark, but I will report of the status as soon as I can get this done. I support the adoption of this draft as a P2PSIP WG item. On 10/25/2011 01:31 AM, Alexander Knauf wrote: > Hi all, > > we updated our draft for Shared Resources (ShaRe) in RELOAD. Link: > > http://tools.ietf.org/html/draft-knauf-p2psip-share-02 > > regards, > > Alexander > > A new version of I-D, draft-knauf-p2psip-share-02.txt has been successfully > submitted by Alexander Knauf and posted to the IETF repository. > > Filename: draft-knauf-p2psip-share > Revision: 02 > Title: A Usage for Shared Resources in RELOAD (ShaRe) > Creation date: 2011-10-24 > WG ID: Individual Submission > Number of pages: 23 > > Abstract: > This document defines a RELOAD Usage for managing shared write access > to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic > primitive for enabling various coordination and notification schemes > among distributed peers. Access in ShaRe is controlled by a > hierarchical trust delegation scheme maintained within an access > list. A new USER-CHAIN-ACL access policy allows authorized peers to > write a Shared Resource without owning its corresponding certificate. > This specification also adds mechanisms to store Resources with a > variable name which is useful whenever peer-independent rendezvous > processes are required. > > > > > The IETF Secretariat > - -- 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) iEYEARECAAYFAk7BUPMACgkQ9RoMZyVa61d+tQCeIoXtA9D8P20lIq4BOkZocAPA a48An3EUgA8MVoRy2rH9L4ejJ65UUqNu =J8mf -----END PGP SIGNATURE----- From petithug@acm.org Mon Nov 14 10:11: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 0D05021F8E10 for ; Mon, 14 Nov 2011 10:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 RKU7LtyLTX7n for ; Mon, 14 Nov 2011 10:11: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 E312321F8E0A for ; Mon, 14 Nov 2011 10:11:10 -0800 (PST) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E2F8720371 for ; Mon, 14 Nov 2011 18:01:31 +0000 (UTC) Message-ID: <4EC159BA.5020909@acm.org> Date: Tue, 15 Nov 2011 02:11:06 +0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: P2PSIP Mailing List References: <4E49B882.7060001@acm.org> In-Reply-To: <4E49B882.7060001@acm.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-sip-06 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: Mon, 14 Nov 2011 18:11:12 -0000 No response to this review, but I have an additional comment on this draft: 11. Section 3 "Note that these rules permit Alice to forward calls to Bob without his permission. However, they do not permit Alice to forward Bob's calls to her." One way to allow Alice to forward Bob's calls to her (or someone else) in a secure way is to use the access control policy defined in draft-knauf-p2psip-share. With -sip-06, only the owner of the certificate can store a SIP-REGISTRATION, that we can represent like this: Resource Kind Node-ID URI signer bob@c.com------1--->0x12345678--->sip:bob@m.com bob@c.com What Share can bring here is the possibility to have an authorized third-party modifying the SIP registration: Resource Kind Node-ID URI signer bob@c.com----1001-->0x12345678--->sip:bob@c.com bob@c.com Resource Kind Index ACL signer bob@c.com-----18--->0x56780001-->bob@c.com 1001 true bob@c.com bob@c.com-----18--->0x56780002-->alice@c.com 1001 false bob@c.com Here Bob (the boss) delegates to Alice (his assistant[1]) the right to modify its registration, so Alice can now change it: Resource Kind Node-ID URI signer bob@c.com----1001-->0x12345678--->sip:alice@m.com alice@c.com One problem is that we cannot reuse the Kind 1 (SIP), because it is already bound to USER-NODE-MATCH, so we have to create a new kind (1001) that is bound to USER-CHAIN-ACL. Unfortunately I do not see an easy solution to use the original Kind (1) with USER-CHAIN-ACL. I would suggest to add an informative reference to draft-p2psip-knauf-share, and to add a similar example in an appendix. [1] For the record, the example I sent to the Share authors had Alice as the boss, and Bob as her assistant, but I had to invert the example to match the text in -sip. On 08/16/2011 08:23 AM, Marc Petit-Huguenin wrote: > 1. Section 3: SipRegistration structure > > I would suggest to use "SipRegistration Resource Record" instead, to match the > terminology in -concepts. > > Same thing for SipRegistration PDU in the same section. > > > 2. Section 3: 1st paragraph > > s/This uses the SIP-REGISTRATION Kind-ID/This uses the SIP-REGISTRATION Kind/ > > > 3. Section 3: opaque contact_prefs<0..2^16-1>; > > The format of the contact_prefs field is not described. Is it RFC 3840 or RFC > 2533 (better in my opinion) or something else? > > > 4. Section 3: Destination destination_list<0..2^16-1>; > > I think it would be better to have a list of destination_list instead, to be > able to register different paths to the destination. This could be useful if a > node decides to register as a client to multiple peers, using the procedure in > the second bullet of section 3.2.1 of -base. > > > 5. Section 3, second bullet of last list. > > It says that the storing peer must check that "[t]he certificate contains a > Node-ID that is the same as the dictionary key it is being stored at.", which is > not exactly true when the certificate contains multiple Node-ID. It would be > better to say: > > "The Node-ID of the signer is the same as the dictionary key it is being stored at." > > > 6. Section 4, first item in list > > "Check to see if the domain part of the AOR matches the domain name of an > overlay of which he is a member." > > The way I understand this sentence, the "sip:petithug@implementers.org" AOR > matches an overlay named "overlay.implementers.org". Was that the intent of > this rule, or was the intent that the "sip:petithug@implementers.org" AOR only > matches the "implementers.org" overlay? > > > 7. Section 5. > > "If certificate-based authentication is in use, the responding peer MUST present > a certificate with a Node-ID matching the terminal entry in the route list." > > If this sentence is about the AppAttach itself (and not about the connection > created by the AppAttach), isn't that rule already part of -base? > > > 8. Section 6. Second sentence. > > I do not understand what this sentence means. > > > 9. Section 8.1. "In this section we discuss security issues that are likely to > be relevant to any usage of RELOAD." > > There is no security issues discussed in section 8.1. > > > 10. Section 9 > > Please change "TBD" by the code point that was already assigned (1, I think), so > early implementations can do interoperability testing. > > > Nits > ==== > > - Abstract > > s/(RELOAD),/(RELOAD)./ > > - Section 2 > > s/consiered/considered/ > -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From petithug@acm.org Mon Nov 14 16:19:21 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 6577411E80D0 for ; Mon, 14 Nov 2011 16:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 2y4JGA18TxLz for ; Mon, 14 Nov 2011 16:19:18 -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 E9D9E1F0C8A for ; Mon, 14 Nov 2011 16:19:09 -0800 (PST) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 17E2520371 for ; Tue, 15 Nov 2011 00:09:29 +0000 (UTC) Message-ID: <4EC1AFFA.6060906@acm.org> Date: Tue, 15 Nov 2011 08:19:06 +0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: P2PSIP Mailing List References: <4E49B882.7060001@acm.org> <4EC159BA.5020909@acm.org> In-Reply-To: <4EC159BA.5020909@acm.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-sip-06 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: Tue, 15 Nov 2011 00:19:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/15/2011 02:11 AM, Marc Petit-Huguenin wrote: > No response to this review, but I have an additional comment on this draft: > > 11. Section 3 > > "Note that these rules permit Alice to forward calls to Bob without > his permission. However, they do not permit Alice to forward Bob's > calls to her." > > One way to allow Alice to forward Bob's calls to her (or someone else) in a > secure way is to use the access control policy defined in > draft-knauf-p2psip-share. With -sip-06, only the owner of the certificate can > store a SIP-REGISTRATION, that we can represent like this: > > Resource Kind Node-ID URI signer > bob@c.com------1--->0x12345678--->sip:bob@m.com bob@c.com > > What Share can bring here is the possibility to have an authorized third-party > modifying the SIP registration: > > Resource Kind Node-ID URI signer > bob@c.com----1001-->0x12345678--->sip:bob@c.com bob@c.com > > Resource Kind Index ACL signer > bob@c.com-----18--->0x56780001-->bob@c.com 1001 true bob@c.com > bob@c.com-----18--->0x56780002-->alice@c.com 1001 false bob@c.com > > Here Bob (the boss) delegates to Alice (his assistant[1]) the right to modify > its registration, so Alice can now change it: > > Resource Kind Node-ID URI signer > bob@c.com----1001-->0x12345678--->sip:alice@m.com alice@c.com > > One problem is that we cannot reuse the Kind 1 (SIP), because it is already > bound to USER-NODE-MATCH, so we have to create a new kind (1001) that is bound > to USER-CHAIN-ACL. Unfortunately I do not see an easy solution to use the > original Kind (1) with USER-CHAIN-ACL. > > I would suggest to add an informative reference to draft-p2psip-knauf-share, and I meant "add an informative reference in draft-ietf-p2psip-sip to draft-knauf-p2psip-share". > to add a similar example in an appendix. > > > [1] For the record, the example I sent to the Share authors had Alice as the > boss, and Bob as her assistant, but I had to invert the example to match the > text in -sip. > > On 08/16/2011 08:23 AM, Marc Petit-Huguenin wrote: >> 1. Section 3: SipRegistration structure >> >> I would suggest to use "SipRegistration Resource Record" instead, to match the >> terminology in -concepts. >> >> Same thing for SipRegistration PDU in the same section. >> >> >> 2. Section 3: 1st paragraph >> >> s/This uses the SIP-REGISTRATION Kind-ID/This uses the SIP-REGISTRATION Kind/ >> >> >> 3. Section 3: opaque contact_prefs<0..2^16-1>; >> >> The format of the contact_prefs field is not described. Is it RFC 3840 or RFC >> 2533 (better in my opinion) or something else? >> >> >> 4. Section 3: Destination destination_list<0..2^16-1>; >> >> I think it would be better to have a list of destination_list instead, to be >> able to register different paths to the destination. This could be useful if a >> node decides to register as a client to multiple peers, using the procedure in >> the second bullet of section 3.2.1 of -base. >> >> >> 5. Section 3, second bullet of last list. >> >> It says that the storing peer must check that "[t]he certificate contains a >> Node-ID that is the same as the dictionary key it is being stored at.", which is >> not exactly true when the certificate contains multiple Node-ID. It would be >> better to say: >> >> "The Node-ID of the signer is the same as the dictionary key it is being stored at." >> >> >> 6. Section 4, first item in list >> >> "Check to see if the domain part of the AOR matches the domain name of an >> overlay of which he is a member." >> >> The way I understand this sentence, the "sip:petithug@implementers.org" AOR >> matches an overlay named "overlay.implementers.org". Was that the intent of >> this rule, or was the intent that the "sip:petithug@implementers.org" AOR only >> matches the "implementers.org" overlay? >> >> >> 7. Section 5. >> >> "If certificate-based authentication is in use, the responding peer MUST present >> a certificate with a Node-ID matching the terminal entry in the route list." >> >> If this sentence is about the AppAttach itself (and not about the connection >> created by the AppAttach), isn't that rule already part of -base? >> >> >> 8. Section 6. Second sentence. >> >> I do not understand what this sentence means. >> >> >> 9. Section 8.1. "In this section we discuss security issues that are likely to >> be relevant to any usage of RELOAD." >> >> There is no security issues discussed in section 8.1. >> >> >> 10. Section 9 >> >> Please change "TBD" by the code point that was already assigned (1, I think), so >> early implementations can do interoperability testing. >> >> >> Nits >> ==== >> >> - Abstract >> >> s/(RELOAD),/(RELOAD)./ >> >> - Section 2 >> >> s/consiered/considered/ >> > - -- 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) iEYEARECAAYFAk7Br/gACgkQ9RoMZyVa61fCTgCfQqApyrWerSBJV55zmG/svCRi zi0An33Zv3DsWywaChy+fWXNQz7aWi68 =L0Lf -----END PGP SIGNATURE----- From haibin.song@huawei.com Mon Nov 14 16:20:02 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 1F7C311E80D3 for ; Mon, 14 Nov 2011 16:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 SXhDwRkE5SAw for ; Mon, 14 Nov 2011 16:20:01 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id DE82311E80D0 for ; Mon, 14 Nov 2011 16:20:00 -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 <0LUO00JVPE92KV@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 15 Nov 2011 08:19:51 +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 <0LUO0061GE92SG@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 15 Nov 2011 08:19:50 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA88378; Tue, 15 Nov 2011 08:19:50 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Nov 2011 08:19:48 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.229]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 15 Nov 2011 08:19:42 +0800 Date: Tue, 15 Nov 2011 00:12:49 +0000 From: Songhaibin In-reply-to: <4EBD3D91.4000803@acm.org> X-Originating-IP: [172.24.2.41] To: Marc Petit-Huguenin Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 Thread-index: AQHMnKFWx43ZR+qgE0y8OqUzpmrZnJWm+pRQgABRVYCABcfQZQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB6B5EE.4000309@acm.org> <4EBD3D91.4000803@acm.org> Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 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: Tue, 15 Nov 2011 00:20:02 -0000 Hi Marc, ________________________________________ From: p2psip-bounces@ietf.org [p2psip-bounces@ietf.org] on behalf of Marc Petit-Huguenin [petithug@acm.org] Sent: Friday, November 11, 2011 11:21 PM To: Songhaibin Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Inline. On 11/11/2011 02:03 AM, Songhaibin wrote: > Hi Marc, > > Thank you very much for the review. See reply in line. > >> -----Original Message----- From: p2psip-bounces@ietf.org >> [mailto:p2psip-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin Sent: >> Monday, November 07, 2011 12:30 AM To: P2PSIP Mailing List Subject: >> [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 [...] > > struct { uint64 expiration; uint64 timestampInitiated; uint64 dMFlags; > DiagnosticExtension diagnostic_extensions<0..2^32-1>; // the length is > already here. } DiagnosticsRequest; > >> struct { uint64 expiration; uint64 timestampInitiated; uint32 length; >> select (length) { case 0: uint64 dMFlags; case > 0: uint64 dMFlags; >> c} } >> DiagnosticsRequest; > >> By using structure, we mean that if the "length" field at the beginning of >> the request equals to "0", there is no other diagnostic information request >> except that contained in the dMFlags. If there are other extension types of >> diagnostic information are requested(as indicated by the length field), >> there will be DiagnosticEXtension field. But it seems there is something >> wrong here. Because in the draft it only allows at most 2^16 extension >> types, the diagnostic_extensions array should also be at most 2^16 long. >> Section 5.1.2 has the same problem. What I meant is that the explicit length field and the implicit length field in the diagnostic_extensions field carry the same value, so why not eliminate one of them. > >> That is to say, "length" is the number of requested extension diagnostic >> types. Really? I would have thought that it was the size, not the number of instances. [Haibin] So We could change the explicit length field to another name, say, number_diag_ext. And "DiagnosticExtension diagnostic_extensions<0..2^32-1> " will be changed to "DiagnosticExtension diagnostic_extensions[number_diag_ext]". > > > Also the authors should choose between the CamelCase convention > (timestampInitiated) or the underscore convention > (diagnostic_extension_contents) but not mix the two. > > >> That's to make it consistent with the base draft. For example, in the base >> draft section 5.3.3.1, the definition of ErrorResponse struct: > >> public struct { uint16 error_code; opaque >> error_info<0..2^16-1>; } ErrorResponse; > >> You see the structure name is in CamelCase, but the variable is in >> underscore convention. Yes, but my point was that timestampInitiated is not consistent with either the base draft or the other fields in this draft. [Haibin] Sorry. I thought you mean in the whole draft. But yes, the authors would find them in the draft and correct them to timestamp_initiated, timestamp_received, and... [...] > > 3. Section 5.1.1, third field definition > > Is the request really allowed to set all dMFlags to '1', and so requesting > diagnostics types that are not yet defined? > > >> Only defined main diagnostics types are requested. From the extensibility >> consideration, it is good to classify the diagnostics types into two, one >> is the main types, the other is the extended types. We use 64 bits dMFlags >> to indicate the main diagnostics types that are requested. If there is >> requirement for more diagnostics types, they can define the extension types >> for use. The request will then contain the diagnostic_extensions<0..2^32-1> >> field as defined in section 5.1.1. That's not what I meant. On the 64 main diagnostics types possibles, only 15 are defined. But the text says that all dMFlags must be set to '1', so it would request types that are not defined yet. Is it the intent? [Haibin] If my understanding is correct, the answer is yes. It would include the types that are to be defined in the future. > > > 4. Section 5.1.3 > > I would add an additional diagnostic kind that provide the OS (or modify > SOFTWARE_VERSION to provide the OS), for the purpose of evaluating if an > overlay as enough OS diversity to handle a bug in a specific OS. > > >> To understand it deeply, could you give an example of what a bug it might >> be and how it will impact the overlay? It's about diversity in an overlay. If all the nodes are using the same RELOAD implementation, then the overlay will not survive a bug in this implementation. So a node can use diagnostics to evaluate the diversity in software implementations. Because OS have bugs too, OS diversity in an overlay is also a good thing, but diagnostics cannot be used for this purpose. [Haibin] I'm okay with adding OS info. Which bring another thing that is missing in diagnostics: The draft should define an XML namespace for the sole purpose of adding it to a element, to force all nodes of an overlay to support diagnostics. [Haibin] I think this suggestion is good. [...] > For error code 101, why using a fixed-length text string, instead of a > "opaque suberror<0..32>" > > >> There are several types when error 101 was returned. We want to make it >> machine readable than just human readable, so as to classify them. I think that a subcode + text with variable length is better than parsing an exact text, something like this: uint8 subcode; opaque reason<0..2^8-1> [Haibin] That's what we did in the previous draft long time ago. BR, -Haibin - -- 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) iEYEARECAAYFAk69PY4ACgkQ9RoMZyVa61eu4gCdEJkyC9YsRpCPutdBLlX6ayB5 xPMAn1PC0oNgCGt0w0ABMMpoMK8zNN9F =s463 -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip From petithug@acm.org Mon Nov 14 16:27:35 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 5521C11E80D3 for ; Mon, 14 Nov 2011 16:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 ws6B8Cmv9mWe for ; Mon, 14 Nov 2011 16:27:34 -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 53F7211E80D0 for ; Mon, 14 Nov 2011 16:27:34 -0800 (PST) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 2871420371; Tue, 15 Nov 2011 00:17:53 +0000 (UTC) Message-ID: <4EC1B1F2.2020109@acm.org> Date: Tue, 15 Nov 2011 08:27:30 +0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: Songhaibin References: <4EB6B5EE.4000309@acm.org> <4EBD3D91.4000803@acm.org> 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] Review of draft-ietf-p2psip-diagnostics-06 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: Tue, 15 Nov 2011 00:27:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/15/2011 08:12 AM, Songhaibin wrote: > Hi Marc, ________________________________________ From: > p2psip-bounces@ietf.org [p2psip-bounces@ietf.org] on behalf of Marc > Petit-Huguenin [petithug@acm.org] Sent: Friday, November 11, 2011 11:21 PM > To: Songhaibin Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Review of > draft-ietf-p2psip-diagnostics-06 > > Inline. > > On 11/11/2011 02:03 AM, Songhaibin wrote: >> Hi Marc, > >> Thank you very much for the review. See reply in line. > >>> -----Original Message----- From: p2psip-bounces@ietf.org >>> [mailto:p2psip-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin Sent: >>> Monday, November 07, 2011 12:30 AM To: P2PSIP Mailing List Subject: >>> [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 > > [...] > > >> struct { uint64 expiration; uint64 timestampInitiated; uint64 dMFlags; >> DiagnosticExtension diagnostic_extensions<0..2^32-1>; // the length is >> already here. } DiagnosticsRequest; > >>> struct { uint64 expiration; uint64 timestampInitiated; uint32 length; >>> select (length) { case 0: uint64 dMFlags; case > 0: uint64 dMFlags; c} } >>> DiagnosticsRequest; > >>> By using structure, we mean that if the "length" field at the beginning >>> of the request equals to "0", there is no other diagnostic information >>> request except that contained in the dMFlags. If there are other >>> extension types of diagnostic information are requested(as indicated by >>> the length field), there will be DiagnosticEXtension field. But it seems >>> there is something wrong here. Because in the draft it only allows at >>> most 2^16 extension types, the diagnostic_extensions array should also be >>> at most 2^16 long. Section 5.1.2 has the same problem. > > What I meant is that the explicit length field and the implicit length field > in the diagnostic_extensions field carry the same value, so why not eliminate > one of them. > > >>> That is to say, "length" is the number of requested extension diagnostic >>> types. > > Really? I would have thought that it was the size, not the number of > instances. > > [Haibin] So We could change the explicit length field to another name, say, > number_diag_ext. And "DiagnosticExtension diagnostic_extensions<0..2^32-1> " > will be changed to "DiagnosticExtension > diagnostic_extensions[number_diag_ext]". That would still redefine the meaning of [], which would be confusing for implementers. What I would suggest is to use the length, and to define this: DiagnosticExtension diagnostic_extensions[length]; [...] > > >> 3. Section 5.1.1, third field definition > >> Is the request really allowed to set all dMFlags to '1', and so requesting >> diagnostics types that are not yet defined? > > >>> Only defined main diagnostics types are requested. From the >>> extensibility consideration, it is good to classify the diagnostics types >>> into two, one is the main types, the other is the extended types. We use >>> 64 bits dMFlags to indicate the main diagnostics types that are >>> requested. If there is requirement for more diagnostics types, they can >>> define the extension types for use. The request will then contain the >>> diagnostic_extensions<0..2^32-1> field as defined in section 5.1.1. > > That's not what I meant. On the 64 main diagnostics types possibles, only > 15 are defined. But the text says that all dMFlags must be set to '1', so it > would request types that are not defined yet. Is it the intent? > > [Haibin] If my understanding is correct, the answer is yes. It would include > the types that are to be defined in the future. > Thanks. > > >> 4. Section 5.1.3 > >> I would add an additional diagnostic kind that provide the OS (or modify >> SOFTWARE_VERSION to provide the OS), for the purpose of evaluating if an >> overlay as enough OS diversity to handle a bug in a specific OS. > > >>> To understand it deeply, could you give an example of what a bug it >>> might be and how it will impact the overlay? > > It's about diversity in an overlay. If all the nodes are using the same > RELOAD implementation, then the overlay will not survive a bug in this > implementation. So a node can use diagnostics to evaluate the diversity in > software implementations. > > Because OS have bugs too, OS diversity in an overlay is also a good thing, > but diagnostics cannot be used for this purpose. > > [Haibin] I'm okay with adding OS info. Thanks. > > Which bring another thing that is missing in diagnostics: The draft should > define an XML namespace for the sole purpose of adding it to a > element, to force all nodes of an overlay to support > diagnostics. > > [Haibin] I think this suggestion is good. Great, thanks. > > [...] > >> For error code 101, why using a fixed-length text string, instead of a >> "opaque suberror<0..32>" > > >>> There are several types when error 101 was returned. We want to make it >>> machine readable than just human readable, so as to classify them. > > I think that a subcode + text with variable length is better than parsing an > exact text, something like this: > > uint8 subcode; opaque reason<0..2^8-1> > > [Haibin] That's what we did in the previous draft long time ago. Ah, sorry! I'll try to find in the mailing-list if there was any discussion explaining this. 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.11 (GNU/Linux) iEYEARECAAYFAk7BsfAACgkQ9RoMZyVa61d2RQCfcAzc21npImYh/lVUeMYzyfHz VmEAniGbJ7kUv/3UNTjFbVK3u1p+scW0 =HrOD -----END PGP SIGNATURE----- From ietf@meetecho.com Wed Nov 16 08:58: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 679CF21F9289 for ; Wed, 16 Nov 2011 08:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 7ELQ7Ywe8D+C for ; Wed, 16 Nov 2011 08:58:53 -0800 (PST) Received: from smtplq02.aruba.it (smtplq-out17.aruba.it [62.149.158.37]) by ietfa.amsl.com (Postfix) with SMTP id 5920621F921E for ; Wed, 16 Nov 2011 08:58:53 -0800 (PST) Received: (qmail 18474 invoked by uid 89); 16 Nov 2011 16:58:52 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq02.aruba.it with SMTP; 16 Nov 2011 16:58:52 -0000 Received: (qmail 16936 invoked by uid 89); 16 Nov 2011 16:58:52 -0000 Received: from unknown (HELO ?192.168.15.117?) (ietf@meetecho.com@114.24.8.77) by smtp2.ad.aruba.it with SMTP; 16 Nov 2011 16:58:51 -0000 Message-ID: <4EC3EBC3.8020004@meetecho.com> Date: Wed, 16 Nov 2011 17:58:43 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Subject: [P2PSIP] Meetecho supporto for P2PSIP WG meeting session 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, 16 Nov 2011 16:58:54 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Thursday's P2PSIP WG meeting session. Access to the on-line session (including audio and video streams) will be available from 1:00pm at: http://www.meetecho.com/ietf82/p2psip The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf82/tutorials For further information you can contact us at ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From ietf@meetecho.com Mon Nov 21 08:48: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 69F3221F8C59 for ; Mon, 21 Nov 2011 08:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 EvfyuHGgoOVg for ; Mon, 21 Nov 2011 08:48:40 -0800 (PST) Received: from smtplq02.aruba.it (smtplq-out17.aruba.it [62.149.158.37]) by ietfa.amsl.com (Postfix) with SMTP id 475D321F8C58 for ; Mon, 21 Nov 2011 08:48:37 -0800 (PST) Received: (qmail 10293 invoked by uid 89); 21 Nov 2011 16:48:34 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq02.aruba.it with SMTP; 21 Nov 2011 16:48:34 -0000 Received: (qmail 29758 invoked by uid 89); 21 Nov 2011 16:48:31 -0000 Received: from unknown (HELO ?143.225.229.189?) (ietf@meetecho.com@143.225.229.189) by smtp3.ad.aruba.it with SMTP; 21 Nov 2011 16:48:31 -0000 Message-ID: <4ECA80D1.5030905@meetecho.com> Date: Mon, 21 Nov 2011 17:48:17 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp3.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Subject: [P2PSIP] P2PSIP session recording available 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: Mon, 21 Nov 2011 16:48:44 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of P2PSIP session at IETF-82 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf82/recordings#P2PSIP For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From haibin.song@huawei.com Thu Nov 24 23:45:56 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 0109421F8B4C for ; Thu, 24 Nov 2011 23:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 a5dpEPLTaDLy for ; Thu, 24 Nov 2011 23:45:55 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9D57C21F8B20 for ; Thu, 24 Nov 2011 23:45:54 -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 <0LV70089SHINBA@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 25 Nov 2011 15:44:48 +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 <0LV700JTJHINXR@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 25 Nov 2011 15:44:47 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFG54496; Fri, 25 Nov 2011 15:44:36 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 25 Nov 2011 15:44:24 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.229]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Fri, 25 Nov 2011 15:44:14 +0800 Date: Fri, 25 Nov 2011 07:44:28 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.129] To: Songhaibin , Marc Petit-Huguenin 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] Review of draft-ietf-p2psip-diagnostics-06 Thread-index: AQHMnKFWx43ZR+qgE0y8OqUzpmrZnJWm+pRQgABRVYCABcfQZYAQPJ7g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB6B5EE.4000309@acm.org> <4EBD3D91.4000803@acm.org> Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 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, 25 Nov 2011 07:45:56 -0000 Marc, >What I meant is that the explicit length field and the implicit length field in the diagnostic_extensions field carry the same value, so why not eliminate one of them. Just noticed that you are right here. I will make the change. BR, -Haibin > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of > Songhaibin > Sent: Tuesday, November 15, 2011 8:13 AM > To: Marc Petit-Huguenin > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 > > Hi Marc, > ________________________________________ > From: p2psip-bounces@ietf.org [p2psip-bounces@ietf.org] on behalf of Marc > Petit-Huguenin [petithug@acm.org] > Sent: Friday, November 11, 2011 11:21 PM > To: Songhaibin > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Inline. > > On 11/11/2011 02:03 AM, Songhaibin wrote: > > Hi Marc, > > > > Thank you very much for the review. See reply in line. > > > >> -----Original Message----- From: p2psip-bounces@ietf.org > >> [mailto:p2psip-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin Sent: > >> Monday, November 07, 2011 12:30 AM To: P2PSIP Mailing List Subject: > >> [P2PSIP] Review of draft-ietf-p2psip-diagnostics-06 > > [...] > > > > > struct { uint64 expiration; uint64 timestampInitiated; uint64 dMFlags; > > DiagnosticExtension diagnostic_extensions<0..2^32-1>; // the length is > > already here. } DiagnosticsRequest; > > > >> struct { uint64 expiration; uint64 timestampInitiated; uint32 length; > >> select (length) { case 0: uint64 dMFlags; case > 0: uint64 dMFlags; > >> c} } > >> DiagnosticsRequest; > > > >> By using structure, we mean that if the "length" field at the beginning of > >> the request equals to "0", there is no other diagnostic information request > >> except that contained in the dMFlags. If there are other extension types of > >> diagnostic information are requested(as indicated by the length field), > >> there will be DiagnosticEXtension field. But it seems there is something > >> wrong here. Because in the draft it only allows at most 2^16 extension > >> types, the diagnostic_extensions array should also be at most 2^16 long. > >> Section 5.1.2 has the same problem. > > What I meant is that the explicit length field and the implicit length field in > the diagnostic_extensions field carry the same value, so why not eliminate one > of them. > > > > >> That is to say, "length" is the number of requested extension diagnostic > >> types. > > Really? I would have thought that it was the size, not the number of instances. > > [Haibin] So We could change the explicit length field to another name, say, > number_diag_ext. And "DiagnosticExtension diagnostic_extensions<0..2^32-1> > " will be changed to "DiagnosticExtension > diagnostic_extensions[number_diag_ext]". > > > > > > > > Also the authors should choose between the CamelCase convention > > (timestampInitiated) or the underscore convention > > (diagnostic_extension_contents) but not mix the two. > > > > > >> That's to make it consistent with the base draft. For example, in the base > >> draft section 5.3.3.1, the definition of ErrorResponse struct: > > > >> public struct { uint16 error_code; opaque > >> error_info<0..2^16-1>; } ErrorResponse; > > > >> You see the structure name is in CamelCase, but the variable is in > >> underscore convention. > > Yes, but my point was that timestampInitiated is not consistent with either the > base draft or the other fields in this draft. > > [Haibin] Sorry. I thought you mean in the whole draft. But yes, the authors would > find them in the draft and correct them to timestamp_initiated, > timestamp_received, and... > > > [...] > > > > > 3. Section 5.1.1, third field definition > > > > Is the request really allowed to set all dMFlags to '1', and so requesting > > diagnostics types that are not yet defined? > > > > > >> Only defined main diagnostics types are requested. From the extensibility > >> consideration, it is good to classify the diagnostics types into two, one > >> is the main types, the other is the extended types. We use 64 bits dMFlags > >> to indicate the main diagnostics types that are requested. If there is > >> requirement for more diagnostics types, they can define the extension types > >> for use. The request will then contain the diagnostic_extensions<0..2^32-1> > >> field as defined in section 5.1.1. > > That's not what I meant. On the 64 main diagnostics types possibles, only 15 > are defined. But the text says that all dMFlags must be set to '1', so it would > request types that are not defined yet. Is it the intent? > > [Haibin] If my understanding is correct, the answer is yes. It would include the > types that are to be defined in the future. > > > > > > > 4. Section 5.1.3 > > > > I would add an additional diagnostic kind that provide the OS (or modify > > SOFTWARE_VERSION to provide the OS), for the purpose of evaluating if an > > overlay as enough OS diversity to handle a bug in a specific OS. > > > > > >> To understand it deeply, could you give an example of what a bug it might > >> be and how it will impact the overlay? > > It's about diversity in an overlay. If all the nodes are using the same RELOAD > implementation, then the overlay will not survive a bug in this implementation. > So a node can use diagnostics to evaluate the diversity in software > implementations. > > Because OS have bugs too, OS diversity in an overlay is also a good thing, but > diagnostics cannot be used for this purpose. > > [Haibin] I'm okay with adding OS info. > > Which bring another thing that is missing in diagnostics: The draft should > define an XML namespace for the sole purpose of adding it to a > element, to force all nodes of an overlay to support > diagnostics. > > [Haibin] I think this suggestion is good. > > [...] > > > For error code 101, why using a fixed-length text string, instead of a > > "opaque suberror<0..32>" > > > > > >> There are several types when error 101 was returned. We want to make it > >> machine readable than just human readable, so as to classify them. > > I think that a subcode + text with variable length is better than parsing an > exact text, something like this: > > uint8 subcode; > opaque reason<0..2^8-1> > > [Haibin] That's what we did in the previous draft long time ago. > > BR, > -Haibin > > - -- > 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) > > iEYEARECAAYFAk69PY4ACgkQ9RoMZyVa61eu4gCdEJkyC9YsRpCPutdBLlX6ayB5 > xPMAn1PC0oNgCGt0w0ABMMpoMK8zNN9F > =s463 > -----END PGP SIGNATURE----- > _______________________________________________ > 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 internet-drafts@ietf.org Tue Nov 29 21:57:43 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 323F621F849D; Tue, 29 Nov 2011 21:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 n8g9kTLkUQ3e; Tue, 29 Nov 2011 21:57:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2421F848E; Tue, 29 Nov 2011 21:57:42 -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.64 Message-ID: <20111130055742.19862.65819.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 21:57:42 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-drr-01.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, 30 Nov 2011 05:57:43 -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 : An extension to RELOAD to support Direct Response Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-drr-01.txt Pages : 18 Date : 2011-11-29 This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-drr-01.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-drr-01.txt From internet-drafts@ietf.org Tue Nov 29 22:00:56 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 0716121F8801; Tue, 29 Nov 2011 22:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 dcg3XsCxz2p0; Tue, 29 Nov 2011 22:00:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D66221F8797; Tue, 29 Nov 2011 22:00:55 -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.64 Message-ID: <20111130060055.21465.18710.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2011 22:00:55 -0800 Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action: draft-ietf-p2psip-rpr-01.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, 30 Nov 2011 06:00:56 -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 : An extension to RELOAD to support Relay Peer Routing Author(s) : Ning Zong Xingfeng Jiang Roni Even Yunfei Zhang Filename : draft-ietf-p2psip-rpr-01.txt Pages : 15 Date : 2011-11-29 This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-01.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-rpr-01.txt From zongning@huawei.com Tue Nov 29 22:39: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 2BE8C21F85A8 for ; Tue, 29 Nov 2011 22:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 LZwtyo8uahal for ; Tue, 29 Nov 2011 22:39:51 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id AD18821F85A7 for ; Tue, 29 Nov 2011 22:39:51 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVG00ISVNRQSS@szxga05-in.huawei.com> for p2psip@ietf.org; Wed, 30 Nov 2011 14:38:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVG004F0NRN28@szxga05-in.huawei.com> for p2psip@ietf.org; Wed, 30 Nov 2011 14:38:14 +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 AFI64851; Wed, 30 Nov 2011 14:37:24 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 Nov 2011 14:37:20 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.86]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 30 Nov 2011 14:37:14 +0800 Date: Wed, 30 Nov 2011 06:37:07 +0000 From: ZongNing X-Originating-IP: [10.138.41.128] To: P2PSIP Mailing List Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_I5QtfYcg5fPzRKkBG+q8VQ)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: New revision of DRR and RPR drafts are available Thread-index: AcyvKn3bnXhI16leTQK4Iff8WVBquw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [P2PSIP] New revision of DRR and RPR drafts are available 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, 30 Nov 2011 06:39:53 -0000 --Boundary_(ID_I5QtfYcg5fPzRKkBG+q8VQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Folks, We have submitted new revision of DRR and RPR drafts to the IETF repository, as linked below: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-drr-01.txt http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-01.txt Co-chairs, as stated in Taipei meeting, we believe the current drafts have addressed all the open issues and ready for WG Last Call. BR, Ning Zong --Boundary_(ID_I5QtfYcg5fPzRKkBG+q8VQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, Folks,

 

We have submitted new revision of DRR and RPR drafts to the IETF repository, as linked below:

http://www.ietf.org/internet-drafts/draft-ietf-p2psip-drr-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-p2psip-rpr-01.txt

 

Co-chairs, as stated in Taipei meeting, we believe the current drafts have addressed all the open issues and ready for WG Last Call.

 

BR,

Ning Zong

--Boundary_(ID_I5QtfYcg5fPzRKkBG+q8VQ)--