From prvs=8095adb53=schmidt@informatik.haw-hamburg.de Sun Apr 14 14:13:40 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D656321F9138 for ; Sun, 14 Apr 2013 14:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799, 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 u2NaUesGgoyp for ; Sun, 14 Apr 2013 14:13:39 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E31A21F8FFB for ; Sun, 14 Apr 2013 14:13:38 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 14 Apr 2013 23:13:37 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 1D00B10AE743 for ; Sun, 14 Apr 2013 23:13:37 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24880-05 for ; Sun, 14 Apr 2013 23:13:36 +0200 (CEST) Received: from [192.168.178.33] (g231110203.adsl.alicedsl.de [92.231.110.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 54B001066AF8 for ; Sun, 14 Apr 2013 23:13:36 +0200 (CEST) Message-ID: <516B1BFF.5090706@informatik.haw-hamburg.de> Date: Sun, 14 Apr 2013 23:13:35 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sam References: <437C8B70-6087-4973-B974-14B444B96101@tony.li> In-Reply-To: <437C8B70-6087-4973-B974-14B444B96101@tony.li> X-Forwarded-Message-Id: <437C8B70-6087-4973-B974-14B444B96101@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: [SAM] Fwd: Re: [irsg] IRSG review for draft-irtf-samrg-common-api X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 21:13:41 -0000 -------- Original Message -------- Subject: Re: [irsg] IRSG review for draft-irtf-samrg-common-api Date: Sun, 14 Apr 2013 13:33:47 -0700 From: Tony Li To: Thomas C. Schmidt CC: 'Internet Research Steering Group' Hi, I have reviewed the document. I find it clear, understandable, and ready to publish (modulo an editorial pass). Regards, Tony On Mar 12, 2013, at 12:50 PM, Thomas C. Schmidt wrote: > Hi all, > > SAMRG searches for a second review / ready to publish vote for draft-irtf-samrg-common-api. > > The document had a first IRSG review by Lisandro and a corresponding upgrade of the draft. > > See http://trac.tools.ietf.org/group/irtf/trac/ticket/50 > > Doc http://www.ietf.org/id/draft-irtf-samrg-common-api-07.txt > > Please help us in completing the document. > > Thanks, > > Thomas on behalf of the document (offline) shepherd John > > > On 19.08.2012 13:52, John Buford wrote: >> All, >> >> SAMRG RG requests an IRSG review for draft-irtf-samrg-common-api-06.txt >> >> http://www.ietf.org/id/draft-irtf-samrg-common-api-06.txt >> >> http://trac.tools.ietf.org/group/irtf/trac/ticket/50 >> >> Please let me know if you can review this draft. >> >> >> Thanks, >> >> John >> > > -- > > Prof. Dr. Thomas C. Schmidt > ° Hamburg University of Applied Sciences Berliner Tor 7 ° > ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° > ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° > ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From waehlisch@ieee.org Mon Apr 15 09:01:14 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75FE21F94A6 for ; Mon, 15 Apr 2013 09:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799, 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 5uatNHGcRTx4 for ; Mon, 15 Apr 2013 09:01:13 -0700 (PDT) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id 027D621F8E47 for ; Mon, 15 Apr 2013 08:59:32 -0700 (PDT) Envelope-to: sam@irtf.org Received: from [194.116.79.226] (helo=mw-PC) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1URloV-0005BO-U6; Mon, 15 Apr 2013 17:59:28 +0200 Date: Mon, 15 Apr 2013 17:59:26 +0200 From: Matthias Waehlisch To: "Thomas C. Schmidt" In-Reply-To: <516B1BFF.5090706@informatik.haw-hamburg.de> Message-ID: References: <437C8B70-6087-4973-B974-14B444B96101@tony.li> <516B1BFF.5090706@informatik.haw-hamburg.de> X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="956132854-21883-1366041566=:8444" X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sam@irtf.org Cc: sam Subject: Re: [SAM] Fwd: Re: [irsg] IRSG review for draft-irtf-samrg-common-api X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:01:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --956132854-21883-1366041566=:8444 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Tony, thanks for your IRSG review! Cheers matthias --=20 Matthias Waehlisch =2E Freie Universitaet Berlin, Inst. fuer Informatik, AG CST =2E Takustr. 9, D-14195 Berlin, Germany =2E. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Sun, 14 Apr 2013, Thomas C. Schmidt wrote: >=20 >=20 >=20 > -------- Original Message -------- > Subject: Re: [irsg] IRSG review for draft-irtf-samrg-common-api > Date: Sun, 14 Apr 2013 13:33:47 -0700 > From: Tony Li > To: Thomas C. Schmidt > CC: 'Internet Research Steering Group' >=20 >=20 > Hi, >=20 > I have reviewed the document. I find it clear, understandable, and ready= to > publish (modulo an editorial pass). >=20 > Regards, > Tony >=20 >=20 > On Mar 12, 2013, at 12:50 PM, Thomas C. Schmidt > wrote: >=20 > > Hi all, > >=20 > > SAMRG searches for a second review / ready to publish vote for > > draft-irtf-samrg-common-api. > >=20 > > The document had a first IRSG review by Lisandro and a corresponding > > upgrade of the draft. > >=20 > > See http://trac.tools.ietf.org/group/irtf/trac/ticket/50 > >=20 > > Doc http://www.ietf.org/id/draft-irtf-samrg-common-api-07.txt > >=20 > > Please help us in completing the document. > >=20 > > Thanks, > >=20 > > Thomas on behalf of the document (offline) shepherd John > >=20 > >=20 > > On 19.08.2012 13:52, John Buford wrote: > > > All, > > >=20 > > > SAMRG RG requests an IRSG review for draft-irtf-samrg-common-api-06.t= xt > > >=20 > > > http://www.ietf.org/id/draft-irtf-samrg-common-api-06.txt > > >=20 > > > http://trac.tools.ietf.org/group/irtf/trac/ticket/50 > > >=20 > > > Please let me know if you can review this draft. > > >=20 > > >=20 > > > Thanks, > > >=20 > > > John > > >=20 > >=20 > > -- > >=20 > > Prof. Dr. Thomas C. Schmidt > > =B0 Hamburg University of Applied Sciences Berliner T= or 7 =B0 > > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Ger= many =B0 > > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-= 8452 =B0 > > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-= 8409 =B0 >=20 >=20 >=20 > _______________________________________________ > SAM mailing list > SAM@irtf.org > http://www.irtf.org/mailman/listinfo/sam >=20 --956132854-21883-1366041566=:8444-- From mko@cs.stir.ac.uk Mon Apr 22 03:19:02 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FF821F8EF2 for ; Mon, 22 Apr 2013 03:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 0R4JeBs98hKq for ; Mon, 22 Apr 2013 03:19:01 -0700 (PDT) Received: from clyde.stir.ac.uk (clyde.stir.ac.uk [139.153.13.35]) by ietfa.amsl.com (Postfix) with ESMTP id 20ED021F8EDF for ; Mon, 22 Apr 2013 03:19:00 -0700 (PDT) Received: from smtp1.stir.ac.uk ([139.153.12.131]) by clyde.stir.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUDpj-0000ek-Ls for sam@irtf.org; Mon, 22 Apr 2013 11:18:51 +0100 Received: from d253090.cs.stir.ac.uk ([139.153.253.90]) by smtp1.stir.ac.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUDpj-00036K-DA for sam@irtf.org; Mon, 22 Apr 2013 11:18:51 +0100 Message-ID: <51750E88.7000904@cs.stir.ac.uk> Date: Mon, 22 Apr 2013 11:18:48 +0100 From: Dr Mario Kolberg User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: sam References: <20130422101431.14161.1049.idtracker@ietfa.amsl.com> In-Reply-To: <20130422101431.14161.1049.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130422101431.14161.1049.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000007050601080506020709" X-stir.ac.uk-MailScanner-ID: 1UUDpj-0000ek-Ls X-stir.ac.uk-MailScanner: Found to be clean Subject: [SAM] Fwd: New Version Notification for draft-irtf-samrg-sam-baseline-protocol-03.txt X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 10:19:02 -0000 This is a multi-part message in MIME format. --------------000007050601080506020709 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi All, we have updated the baseline draft after the review by Michael Welz. Please see below for links to the new version. Our response to Michael's comments follows in a separate email. Thanks, Mario & John -------- Original Message -------- A new version of I-D, draft-irtf-samrg-sam-baseline-protocol-03.txt has been successfully submitted by John Buford and posted to the IETF repository. Filename: draft-irtf-samrg-sam-baseline-protocol Revision: 03 Title: Application Layer Multicast Extensions to RELOAD Creation date: 2013-04-22 Group: samrg Number of pages: 39 URL: http://www.ietf.org/internet-drafts/draft-irtf-samrg-sam-baseline-protocol-03.txt Status: http://datatracker.ietf.org/doc/draft-irtf-samrg-sam-baseline-protocol Htmlized: http://tools.ietf.org/html/draft-irtf-samrg-sam-baseline-protocol-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-irtf-samrg-sam-baseline-protocol-03 Abstract: We define a RELOAD Usage for Application Layer Multicast as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay-independent way. Two example algorithms are defined, based on Scribe and P2PCast. The IETF Secretariat ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3272 / Virus Database: 3162/6263 - Release Date: 04/21/13 -- The University of Stirling is ranked in the top 50 in the world in The Times Higher Education 100 Under 50 table, which ranks the world's best 100 universities under 50 years old. The University of Stirling is a charity registered in Scotland, number SC 011159. --------------000007050601080506020709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi All,

we have updated the baseline draft after the review by Michael Welz. Please see below for links to the new version. Our response to Michael's comments follows in a separate email.

Thanks,
Mario & John


-------- Original Message -------- 









A new version of I-D, draft-irtf-samrg-sam-baseline-protocol-03.txt
has been successfully submitted by John Buford and posted to the
IETF repository.

Filename:	 draft-irtf-samrg-sam-baseline-protocol
Revision:	 03
Title:		 Application Layer Multicast Extensions to RELOAD
Creation date:	 2013-04-22
Group:		 samrg
Number of pages: 39
URL:             http://www.ietf.org/internet-drafts/draft-irtf-samrg-sam-baseline-protocol-03.txt
Status:          http://datatracker.ietf.org/doc/draft-irtf-samrg-sam-baseline-protocol
Htmlized:        http://tools.ietf.org/html/draft-irtf-samrg-sam-baseline-protocol-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-irtf-samrg-sam-baseline-protocol-03

Abstract:
   We define a RELOAD Usage for Application Layer Multicast as well as a
   mapping to the RELOAD experimental message type to support ALM.  The
   ALM Usage is intended to support a variety of ALM control algorithms
   in an overlay-independent way.  Two example algorithms are defined,
   based on Scribe and P2PCast.

                                                                                  


The IETF Secretariat



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3272 / Virus Database: 3162/6263 - Release Date: 04/21/13
The University of Stirling is ranked in the top 50 in the world in The Times Higher Education 100 Under 50 table, which ranks the world's best 100 universities under 50 years old.
The University of Stirling is a charity registered in Scotland, number SC 011159.
--------------000007050601080506020709-- From mko@cs.stir.ac.uk Mon Apr 22 03:37:27 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4215921F8D2E for ; Mon, 22 Apr 2013 03:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 F73jEp1Jbavg for ; Mon, 22 Apr 2013 03:37:22 -0700 (PDT) Received: from bannock.stir.ac.uk (bannock.stir.ac.uk [139.153.12.54]) by ietfa.amsl.com (Postfix) with ESMTP id 72FB621F8D14 for ; Mon, 22 Apr 2013 03:37:22 -0700 (PDT) Received: from smtp1.stir.ac.uk ([139.153.12.131]) by bannock.stir.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUE7Q-0008Dn-E7; Mon, 22 Apr 2013 11:37:08 +0100 Received: from d253090.cs.stir.ac.uk ([139.153.253.90]) by smtp1.stir.ac.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UUE7Q-0003EZ-5Y; Mon, 22 Apr 2013 11:37:08 +0100 Message-ID: <517512C6.80707@cs.stir.ac.uk> Date: Mon, 22 Apr 2013 11:36:54 +0100 From: Dr Mario Kolberg User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Michael Welzl , sam References: <01b601ce39fc$b3c1afc0$1b450f40$@samrg.org> In-Reply-To: <01b601ce39fc$b3c1afc0$1b450f40$@samrg.org> Content-Type: multipart/alternative; boundary="------------060908020902060707050804" X-stir.ac.uk-MailScanner-ID: 1UUE7Q-0008Dn-E7 X-stir.ac.uk-MailScanner: Found to be clean Subject: Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 10:37:27 -0000 This is a multi-part message in MIME format. --------------060908020902060707050804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Michael and All, please find below our response to the IRSG review by Michael Welzl. Best wishes, Mario & John > > General higher-level comments: > > 1) I found parts of the document very hard to read, sometimes wondered > if this is really necessary. > The document is intended for an audience which does have a technical background in the area of application layer multicasting and peer to peer overlay protocols. We would expect readers unfamiliar with the area to first go to more basic material. Perhaps many comments in the review stem from the fact that the reviewer doesn't have this familiarity. To help readers to get a better understanding we have added references to introductory and background material as a starting point: J. Buford, H. Yu, E. K. Lua P2P Networking and Applications. Morgan Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting). M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon). J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in: Encyclopedia of Wireless and Mobile Communications. 2008. > 2) In particular, P2PCast appears to be a rather complex algorithm > which is "sort of" described here... I doubt that the description in > the document will help most readers to really fully understand > P2PCast, and I wonder, is it necessary for this doc to try to really > explain the algorithm (when, in doing so, it can really only go > half-way anyway)? e.g., wouldn't it suffice to just keep the > "Overview" (section 9.1) but then point to [P2PCAST] for further > details, and just list the necessary facts? e.g., the JOIN procedure - > do we have to know all these details here, isn't it enough to e.g. > list the reorganisation messages by name and say that they're used in > accordance with [P2PCAST]? The ID is written for a technical audience which is presumed to be knowledgeable about RELOAD and P2P overlays and has somefamiliarity with multicasting at the application layer. We provide summaries of P2PCAST and SCRIBE since these two algorithms are well known in the ALM research community, and are each representative of an important class of ALM algorithms. If the reader needs more background, then they can go to thereference papers and find it there. In our opinion, the inclusion of the essential features about each algorithm is useful and should be in the ID. The level of detaildescribes "Scribe-like" and "P2PCast-like" algorithms, and not only Scribe and P2PCAST. Since the protocol we define is intended to support a large variety of such algorithms. This is done in other in other IDs and RFCs. For example, please take a look at section 10 of the RELOAD ID which gives detailed information about the Chord algorithm, but yet omits Chord details which one would find in the original papers from MIT. If your comments were followed, this Chord material should be removed from RELOAD spec. Likewise see this id produced by the PPSP WG draft-ietf-ppsp-survey-04. There are lots of other examples where important previously existing algorithms are summarized in an ID. > 3) Another source of confusion: the Scribe algorithm description has > some pseudocode that I wasn't able to parse (maybe it refers to RELOAD > things?) Not all functions there seem to clearly relate to messages > that were described earlier. Even more confusing, the P2PCast > algorithm description doesn't have these pseudocode snippets, so the > whole thing appears inconsistent. Should it be everywhere? Should it > be removed? If it stays, some explanations are needed. It can't be up > to the reader to guess what e.g. "invokeMessageHandler" does, right?? > (section 8.7). In this particular section, I would also expect the > text and/or pseudocode to somehow draw a relationship to "push" > (listed in fig. 3), but that's not there... so what is this? We agree that this pseudocode is more general and applies to both algorithms. To avoid duplication, we have moved it from Section 8 to the relevant subsections in Section 7. > > 4) Structure: even if the two algorithms are only a part of the whole > thing you define, the text going with them feels a bit like "we've set > the stage, now we apply it - the messages you heard about before are > used like this & that with this & that algorithm". That's fine! But it > also gives the reader the feeling of that being "part 2", i.e. I think > it should be at the end, if that makes sense. > Yes the algorithms are an application of the material in earlier sections, but we don't agree that moving it to the end will help the understanding of the draft. > 5) I also think that it would be better to move the examples (section > 12) to where you introduce the messages, the flow of which they > illustrate. First I have to imagine what an "INVITE" message flow > could look like, then I get complicated explanations of how INVITE is > applied in an algorithm that I can't fully understand from this text > anyway, and THEN I get a nice example illustrating an INVITE message > flow... that's not very helpful for the reader I think. e.g., when I > read 7.2.3, I wondered why the "peer_id" of the source peer is even > needed in the struct. By looking at the example, this would have > become clear to me. > The document is not meant to be a tutorial, hence the examples are not first. The examples follow the definition of the messages sothat the message use is illustrated. If we moved the examples first, then some other reviewer could then say ... why are the examplesshown before the protocol messages are defined? It is not the purpose of the ID to bootstrap the reader into basic knowledge of ALM and Peer to Peer messaging. > 6) Speaking of the examples, what's the point of showing more peers > than you actually use in the example? Okay, I can understand that > perhaps you wanted to have the same number for all of them, but then > you could still remove P3 because it seems that you never use P3 for > anything in any of the examples. We added these peers is to illustrate that 1) not all the peers in the overlay have to be part of each ALM connection, and 2) the overlay could have an arbitrary number of peers. > 7) Nits: > > IANA Considerations: are you sure that there is nothing? e.g., how > would a new algorithm code be assigned? (section 11.4) > - btw, why is the section called "Algorithm Codes" but then the text > talks about "Algorithm Types" ? > There are no IANA considerations since this is to be an informational RFC. > > 8) Some references (CASTRO2003, P2PCAST) need a space (I mean, " ") > after their first appearance. > cut..... > All these edits have been done and version 03 has been submitted. -- The University of Stirling is ranked in the top 50 in the world in The Times Higher Education 100 Under 50 table, which ranks the world's best 100 universities under 50 years old. The University of Stirling is a charity registered in Scotland, number SC 011159. --------------060908020902060707050804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Michael and All,

please find below our response to the IRSG review by Michael Welzl.

Best wishes,
Mario & John
 

General higher-level comments:

1) I found parts of the document very hard to read, sometimes wondered if this is really necessary.

The document is intended for an audience which does have a technical background in the area of application layer multicasting and peer to peer overlay protocols.  We would expect readers unfamiliar with the area to first go to more basic material. Perhaps many comments in the review stem from the fact that the reviewer doesn’t have this familiarity. To help readers to get a better understanding we have added references to introductory and background material as a starting point:

J. Buford, H. Yu, E. K. Lua P2P Networking and Applications. Morgan Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting).
M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon).
J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in: Encyclopedia of Wireless and Mobile Communications. 2008.

2) In particular, P2PCast appears to be a rather complex algorithm which is "sort of" described here... I doubt that the description in the document will help most readers to really fully understand P2PCast, and I  wonder, is it necessary for this doc to try to really explain the algorithm (when, in doing so, it can really only go half-way anyway)? e.g., wouldn't it suffice to just keep the "Overview" (section 9.1) but then point to [P2PCAST] for further details, and just list the necessary facts? e.g., the JOIN procedure - do we have to know all these details here, isn't it enough to e.g. list the reorganisation messages by name and say that they're used in accordance with [P2PCAST]?
The ID is written for a technical audience which is presumed to be knowledgeable about RELOAD and P2P overlays and has some familiarity with multicasting at the application layer.  We provide summaries of P2PCAST and SCRIBE since these two algorithms are well known in the ALM research community, and are each representative of an important class of ALM algorithms.  If the reader needs more background, then they can go to the reference papers and find it there.

In our opinion, the inclusion of the essential features about each algorithm is useful and should be in the ID.  The level of detail describes  “Scribe-like” and “P2PCast-like” algorithms, and not only Scribe and P2PCAST.  Since the protocol we define is intended to support a large variety of such algorithms.

This is done in other in other IDs and RFCs.   For example, please take a look at section 10 of the RELOAD ID which gives detailed information about the Chord algorithm, but yet omits Chord details which one would find in the original papers from MIT. If your comments were followed, this Chord material should be removed from RELOAD spec.      Likewise see this id produced by the PPSP WG draft-ietf-ppsp-survey-04.  There are lots of other examples where important previously existing algorithms are summarized in an ID.

3) Another source of confusion: the Scribe algorithm description has some pseudocode that I wasn't able to parse (maybe it refers to RELOAD things?) Not all functions there seem to clearly relate to messages that were described earlier. Even more confusing, the P2PCast algorithm description doesn't have these pseudocode snippets, so the whole thing appears inconsistent. Should it be everywhere? Should it be removed? If it stays, some explanations are needed. It can't be up to the reader to guess what e.g. "invokeMessageHandler" does, right?? (section 8.7). In this particular section, I would also expect the text and/or pseudocode to somehow draw a relationship to "push" (listed in fig. 3), but that's not there... so what is this?

 We agree that this pseudocode is more general and applies to both algorithms. To avoid duplication, we have moved it from Section 8 to the relevant subsections in Section 7. 

4) Structure: even if the two algorithms are only a part of the whole thing you define, the text going with them feels a bit like "we've set the stage, now we apply it - the messages you heard about before are used like this & that with this & that algorithm". That's fine! But it also gives the reader the feeling of that being "part 2", i.e. I think it should be at the end, if that makes sense.

Yes the algorithms are an application of the material in earlier sections, but we don't agree that moving it to the end will help the understanding of the draft.

5) I also think that it would be better to move the examples (section 12) to where you introduce the messages, the flow of which they illustrate. First I have to imagine what an "INVITE" message flow could look like, then I get complicated explanations of how INVITE is applied in an algorithm that I can't fully understand from this text anyway, and THEN I get a nice example illustrating an INVITE message flow... that's not very helpful for the reader I think.  e.g., when I read 7.2.3, I wondered why the "peer_id" of the source peer is even needed in the struct. By looking at the example, this would have become clear to me.

The document is not meant to be a tutorial, hence the examples are not first.  The examples follow the definition of the messages so that the message use is illustrated.  If we moved the examples first, then some other reviewer could then say … why are the examples shown before the protocol messages are defined? It is not the purpose of the ID to bootstrap the reader into basic knowledge of ALM and Peer to Peer messaging.

6) Speaking of the examples, what's the point of showing more peers than you actually use in the example? Okay, I can understand that perhaps you wanted to have the same number for all of them, but then you could still remove P3 because it seems that you never use P3 for anything in any of the examples.

We added these peers is to illustrate that 1) not all the peers in the overlay have to be part of each ALM connection, and 2) the overlay could have an arbitrary number of peers.

7) Nits:

IANA Considerations: are you sure that there is nothing? e.g., how would a new algorithm code be assigned?   (section 11.4)
- btw, why is the section called "Algorithm Codes" but then the text talks about "Algorithm Types" ?

There are no IANA considerations since this is to be an informational RFC.

8) Some references (CASTRO2003, P2PCAST) need a space (I mean, " ") after their first appearance.
cut.....

All these edits have been done and version 03 has been submitted.
The University of Stirling is ranked in the top 50 in the world in The Times Higher Education 100 Under 50 table, which ranks the world's best 100 universities under 50 years old.
The University of Stirling is a charity registered in Scotland, number SC 011159.
--------------060908020902060707050804-- From michawe@ifi.uio.no Wed Apr 24 07:06:24 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E5A21F8E9E for ; Wed, 24 Apr 2013 07:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, 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 mixsKht0pXY3 for ; Wed, 24 Apr 2013 07:06:23 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id E585521F8E7A for ; Wed, 24 Apr 2013 07:06:22 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UV0Ky-00040c-NS; Wed, 24 Apr 2013 16:06:20 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UV0Kx-0004gX-Nr; Wed, 24 Apr 2013 16:06:20 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E41A76D5-B261-43C2-B67D-811566AE1F20" From: Michael Welzl In-Reply-To: <517512C6.80707@cs.stir.ac.uk> Date: Wed, 24 Apr 2013 16:06:17 +0200 Message-Id: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> References: <01b601ce39fc$b3c1afc0$1b450f40$@samrg.org> <517512C6.80707@cs.stir.ac.uk> To: Dr Mario Kolberg X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 9 sum msgs/h 3 total rcpts 3842 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.6, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.552, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 34B1F54527FEF5BB7C9DC6A86F0E32B75709B48C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -55 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1708 max/h 12 blacklist 0 greylist 0 ratelimit 0 Cc: sam Subject: Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:06:25 -0000 --Apple-Mail=_E41A76D5-B261-43C2-B67D-811566AE1F20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, In line: On 22. apr. 2013, at 12:36, Dr Mario Kolberg wrote: > Hi Michael and All, >=20 > please find below our response to the IRSG review by Michael Welzl. >=20 > Best wishes, > Mario & John > =20 >>=20 >> General higher-level comments:=20 >>=20 >> 1) I found parts of the document very hard to read, sometimes = wondered if this is really necessary. >>=20 > The document is intended for an audience which does have a technical = background in the area of application layer multicasting and peer to = peer overlay protocols. We would expect readers unfamiliar with the = area to first go to more basic material. Perhaps many comments in the = review stem from the fact that the reviewer doesn=92t have this = familiarity. To help readers to get a better understanding we have added = references to introductory and background material as a starting point: > J. Buford, H. Yu, E. K. Lua P2P Networking and Applications. Morgan = Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting). > M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of = Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon). > J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in: Encyclopedia = of Wireless and Mobile Communications. 2008. >=20 Good! I would like to mention that, while I know very little about application = layer multicast, I do have some (outdated) P2P knowledge. It's not = really my field, but I have done a little bit of work on it and also = taught a lecture about it a few years ago (which even contained a brief = overview of Scribe, IIRC). So that made me think, someone like me should = at least be able to make some sense of the document - within certain = limits of course, as I know nothing about RELOAD, for example. >> 2) In particular, P2PCast appears to be a rather complex algorithm = which is "sort of" described here... I doubt that the description in the = document will help most readers to really fully understand P2PCast, and = I wonder, is it necessary for this doc to try to really explain the = algorithm (when, in doing so, it can really only go half-way anyway)? = e.g., wouldn't it suffice to just keep the "Overview" (section 9.1) but = then point to [P2PCAST] for further details, and just list the necessary = facts? e.g., the JOIN procedure - do we have to know all these details = here, isn't it enough to e.g. list the reorganisation messages by name = and say that they're used in accordance with [P2PCAST]? > The ID is written for a technical audience which is presumed to be = knowledgeable about RELOAD and P2P overlays and has some familiarity = with multicasting at the application layer. We provide summaries of = P2PCAST and SCRIBE since these two algorithms are well known in the ALM = research community, and are each representative of an important class of = ALM algorithms. If the reader needs more background, then they can go = to the reference papers and find it there. > In our opinion, the inclusion of the essential features about each = algorithm is useful and should be in the ID. The level of detail = describes =93Scribe-like=94 and =93P2PCast-like=94 algorithms, and not = only Scribe and P2PCAST. Since the protocol we define is intended to = support a large variety of such algorithms. >=20 > This is done in other in other IDs and RFCs. For example, please = take a look at section 10 of the RELOAD ID which gives detailed = information about the Chord algorithm, but yet omits Chord details which = one would find in the original papers from MIT. If your comments were = followed, this Chord material should be removed from RELOAD spec. = Likewise see this id produced by the PPSP WG draft-ietf-ppsp-survey-04. = There are lots of other examples where important previously existing = algorithms are summarized in an ID. Well. I'm not sure if the cases you compare here really are comparable - = the Chord text in the RELOAD ID is much longer, for a (it seems to me) = much simpler algorithm, and a survey is really a different case, I think = - its overall intention is different from a document like this one. But = I see your point about trying to convey the essential features right = here, and if you feel the text explains the essential bits and is = helpful, I'll trust you on this one, given my lack of expertise in = application-layer multicast. >> 3) Another source of confusion: the Scribe algorithm description has = some pseudocode that I wasn't able to parse (maybe it refers to RELOAD = things?) Not all functions there seem to clearly relate to messages that = were described earlier. Even more confusing, the P2PCast algorithm = description doesn't have these pseudocode snippets, so the whole thing = appears inconsistent. Should it be everywhere? Should it be removed? If = it stays, some explanations are needed. It can't be up to the reader to = guess what e.g. "invokeMessageHandler" does, right?? (section 8.7). In = this particular section, I would also expect the text and/or pseudocode = to somehow draw a relationship to "push" (listed in fig. 3), but that's = not there... so what is this? >=20 > We agree that this pseudocode is more general and applies to both = algorithms. To avoid duplication, we have moved it from Section 8 to the = relevant subsections in Section 7. =20 Fine. >> 4) Structure: even if the two algorithms are only a part of the whole = thing you define, the text going with them feels a bit like "we've set = the stage, now we apply it - the messages you heard about before are = used like this & that with this & that algorithm". That's fine! But it = also gives the reader the feeling of that being "part 2", i.e. I think = it should be at the end, if that makes sense. >>=20 > Yes the algorithms are an application of the material in earlier = sections, but we don't agree that moving it to the end will help the = understanding of the draft.=20 Fine. >> 5) I also think that it would be better to move the examples (section = 12) to where you introduce the messages, the flow of which they = illustrate. First I have to imagine what an "INVITE" message flow could = look like, then I get complicated explanations of how INVITE is applied = in an algorithm that I can't fully understand from this text anyway, and = THEN I get a nice example illustrating an INVITE message flow... that's = not very helpful for the reader I think. e.g., when I read 7.2.3, I = wondered why the "peer_id" of the source peer is even needed in the = struct. By looking at the example, this would have become clear to me. >>=20 > The document is not meant to be a tutorial, hence the examples are not = first. The examples follow the definition of the messages so that the = message use is illustrated. If we moved the examples first, then some = other reviewer could then say =85 why are the examples shown before the = protocol messages are defined? It is not the purpose of the ID to = bootstrap the reader into basic knowledge of ALM and Peer to Peer = messaging. >=20 Fine. >> 6) Speaking of the examples, what's the point of showing more peers = than you actually use in the example? Okay, I can understand that = perhaps you wanted to have the same number for all of them, but then you = could still remove P3 because it seems that you never use P3 for = anything in any of the examples. >=20 > We added these peers is to illustrate that 1) not all the peers in the = overlay have to be part of each ALM connection, and 2) the overlay could = have an arbitrary number of peers. Well, even a total P2P nut like myself understands that without even = seeing P3, but whatever :-) >> 7) Nits: >>=20 >> IANA Considerations: are you sure that there is nothing? e.g., how = would a new algorithm code be assigned? (section 11.4)=20 >> - btw, why is the section called "Algorithm Codes" but then the text = talks about "Algorithm Types" ? >>=20 > There are no IANA considerations since this is to be an informational = RFC. Ah, ok, sure - >> 8) Some references (CASTRO2003, P2PCAST) need a space (I mean, " ") = after their first appearance.=20 >> cut..... > All these edits have been done and version 03 has been submitted.=20 Fine, thanks! Cheers, Michael --Apple-Mail=_E41A76D5-B261-43C2-B67D-811566AE1F20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=20 =20
Hi Michael and All,

please find below our response to the IRSG review by Michael Welzl.

Best wishes,
Mario & John
 

General = higher-level comments:

1) I found parts of the = document very hard to read, sometimes wondered if this is really = necessary.

The document is intended for an audience which does have a technical background in the area of application layer multicasting and peer to peer overlay protocols.  We would = expect readers unfamiliar with the area to first go to more basic material. Perhaps many comments in the review stem from the fact that the reviewer doesn=92t have this familiarity. To help readers to get a better understanding we have added references to introductory and background material as a starting = point:

J. Buford, H. Yu, E. = K. Lua P2P Networking and Applications. Morgan Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting).
M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon).
J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in: Encyclopedia of Wireless and Mobile Communications. = 2008.

Good!
I would like to = mention that, while I know very little about application layer = multicast, I do have some (outdated) P2P knowledge. It's not really my = field, but I have done a little bit of work on it and also taught a = lecture about it a few years ago (which even contained a brief overview = of Scribe, IIRC). So that made me think, someone like me should at least = be able to make some sense of the document - within certain limits of = course, as I know nothing about RELOAD, for = example.


2) In particular, P2PCast appears to be = a rather complex algorithm which is "sort of" described here... I doubt that the description in the document will help most readers to really fully understand P2PCast, and I  wonder, = is it necessary for this doc to try to really explain the algorithm (when, in doing so, it can really only go half-way anyway)? e.g., wouldn't it suffice to just keep the "Overview" (section 9.1) but then point to [P2PCAST] for further details, and just list the necessary facts? e.g., the JOIN procedure - do we have to know all these details here, isn't it enough to e.g. list the reorganisation messages by name and say that they're used in accordance with [P2PCAST]?
The ID is written for a technical audience which is presumed to be knowledgeable about RELOAD and P2P overlays and has = some familiarity with multicasting at the application layer.  = We provide summaries of P2PCAST and SCRIBE since these two algorithms are well known in the ALM research community, and are each representative of an important class of ALM algorithms.  If = the reader needs more background, then they can go to the reference papers and find it there.

In our opinion, the inclusion of the essential features about each algorithm is useful and should be in the ID.  The level of detail describes  =93Scribe-like=94 and =93P2PCast-like=94 algorithms, and = not only Scribe and P2PCAST.  Since the protocol we define is = intended to support a large variety of such algorithms.

This is done in other in other IDs and RFCs.   For = example, please take a look at section 10 of the RELOAD ID which gives detailed information about the Chord algorithm, but yet omits Chord details which one would find in the original papers from MIT. If your comments were followed, this Chord material should be removed from RELOAD spec.      Likewise see this id = produced by the PPSP WG draft-ietf-ppsp-survey-04.  There are lots of other examples = where important previously existing algorithms are summarized in an = ID.

Well. I'm not sure = if the cases you compare here really are comparable - the Chord text in = the RELOAD ID is much longer, for a (it seems to me) much simpler = algorithm, and a survey is really a different case, I think - its = overall intention is different from a document like this one. But I see = your point about trying to convey the essential features right here, and = if you feel the text explains the essential bits and is helpful, I'll = trust you on this one, given my lack of expertise in application-layer = multicast.


=20
3) Another source of confusion: the = Scribe algorithm description has some pseudocode that I wasn't able to parse (maybe it refers to RELOAD things?) Not all functions there seem to clearly relate to messages that were described earlier. Even more confusing, the P2PCast algorithm description doesn't have these pseudocode snippets, so the whole thing appears inconsistent. Should it be everywhere? Should it be removed? If it stays, some explanations are needed. It can't be up to the reader to guess what e.g. "invokeMessageHandler" does, right?? (section 8.7). In this particular section, I would also expect the text and/or pseudocode to somehow draw a relationship to "push" (listed in fig. 3), but that's not there... so what is this?

 We agree that this pseudocode is more general and = applies to both algorithms. To avoid duplication, we have moved it from Section 8 to the relevant subsections in Section = 7.  =

Fine.

4) Structure: = even if the two algorithms are only a part of the whole thing you define, the text going with them feels a bit like "we've set the stage, now we apply it - the messages you heard about before are used like this & that with this & that algorithm". That's fine! But it also gives the reader the feeling of that being "part 2", i.e. I think it should be at the end, if that makes = sense.

Yes the algorithms are an application of the material in earlier sections, but we don't agree that moving it to the end will help the understanding of the draft. =

Fine.

=20

5) I also think = that it would be better to move the examples (section 12) to where you introduce the messages, the flow of which they illustrate. First I have to imagine what an "INVITE" message flow could look like, then I get complicated explanations of how INVITE is applied in an algorithm that I can't fully understand from this text anyway, and THEN I get a nice example illustrating an INVITE message flow... that's not very helpful for the reader I think.  = e.g., when I read 7.2.3, I wondered why the "peer_id" of the source peer is even needed in the struct. By looking at the example, this would have become clear to me.

The document is not meant to be = a tutorial, hence the examples are not first.  The examples follow the definition of the messages so that the message use is illustrated.  If we moved the examples first, then some = other reviewer could then say =85 why are the examples = shown before the protocol messages are defined? It is not the purpose of the ID to bootstrap the reader into basic knowledge of ALM and Peer to Peer messaging. =

Fine.

6) Speaking of the examples, = what's the point of showing more peers than you actually use in the example? Okay, I can understand that perhaps you wanted to have the same number for all of them, but then you could still remove P3 because it seems that you never use P3 for anything in any of the examples.

We added these peers is to illustrate that 1) not all the peers in the overlay have to be part of each ALM connection, and 2) the overlay could have an arbitrary number of = peers.

Well, even a total P2P nut = like myself understands that without even seeing P3, but = whatever  :-)

7) = Nits:

IANA Considerations: are you = sure that there is nothing? e.g., how would a new algorithm code be assigned?   (section 11.4)
- btw, why is the section called "Algorithm Codes" but then the text talks about "Algorithm Types" ?

There are no IANA considerations since this is to be an informational RFC.

Ah, ok, sure = -

8) Some references (CASTRO2003, P2PCAST) need a space (I mean, " ") after their first appearance.
cut.....

All these edits have been done and version 03 has been = submitted.

Fine, = thanks!

Cheers,
Michael

<= /div>
= --Apple-Mail=_E41A76D5-B261-43C2-B67D-811566AE1F20-- From prvs=822619329=schmidt@informatik.haw-hamburg.de Sat Apr 27 06:25:14 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB4321F986A; Sat, 27 Apr 2013 06:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799, 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 witLiVpaBw8v; Sat, 27 Apr 2013 06:25:13 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id C82B121F9868; Sat, 27 Apr 2013 06:25:11 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 27 Apr 2013 15:25:09 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 99BC61064E01; Sat, 27 Apr 2013 15:25:09 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30762-10; Sat, 27 Apr 2013 15:25:09 +0200 (CEST) Received: from [192.168.178.33] (e178059151.adsl.alicedsl.de [85.178.59.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id A1C521066AEF; Sat, 27 Apr 2013 15:25:08 +0200 (CEST) Message-ID: <517BD1B0.2060007@informatik.haw-hamburg.de> Date: Sat, 27 Apr 2013 15:25:04 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Internet Research Steering Group Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: sam Subject: [SAM] IRSG Poll for draft-irtf-samrg-sam-baseline-protocol-02 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 13:25:14 -0000 Folks, SAMRG has completed work on the informational document draft-irtf-samrg-sam-baseline-protocol-02. Michael Welzl has performed the IRSG review and authors have updated accordingly, see http://trac.tools.ietf.org/group/irtf/trac/ticket/54. This mail initiates a 3 weeks IRSG poll following the IRSG review process, see http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#Reviews. The poll ends on May 18th. We need two "ready to publish" votes to progress the document. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From buford@samrg.org Sat Apr 27 07:08:00 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06CB21F98AD for ; Sat, 27 Apr 2013 07:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, 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 ni03EzPGkH6s for ; Sat, 27 Apr 2013 07:08:00 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 437F421F98AB for ; Sat, 27 Apr 2013 07:08:00 -0700 (PDT) Received: (qmail 19802 invoked by uid 0); 27 Apr 2013 14:07:37 -0000 Received: from unknown (HELO host181.hostmonster.com) (74.220.207.181) by oproxy9.bluehost.com with SMTP; 27 Apr 2013 14:07:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samrg.org; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=svN0P3qL43/C+EDUd65i+jKtx1lGVYKORNnTB3DC/lI=; b=PiPKg5iuPu+/lkSIaDgUFkHyQFzuZxHMYiuoXCNhlD+gG/H12S/f9hagHGysd4p3EQthyHf559Xhvy2CXMpnnD6/0Br2g4co5QOQudMi9gKXTftb6alY0qjVm1C9S4ks; Received: from [68.38.211.16] (port=55443 helo=Avalon) by host181.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UW5mq-00085k-ND; Sat, 27 Apr 2013 08:07:36 -0600 From: "John Buford" To: "'Thomas C. Schmidt'" , "'Internet Research Steering Group'" References: <517BD1B0.2060007@informatik.haw-hamburg.de> In-Reply-To: <517BD1B0.2060007@informatik.haw-hamburg.de> Date: Sat, 27 Apr 2013 10:07:35 -0400 Message-ID: <014e01ce4350$92314430$b693cc90$@samrg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGxCZyUKHndlpuT2lDY5yhpkzsWRZkkjYXA Content-Language: en-us X-Identified-User: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth 68.38.211.16 authed with buford@samrg.org} Cc: 'sam' Subject: Re: [SAM] [irsg] IRSG Poll for draft-irtf-samrg-sam-baseline-protocol-02 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 14:08:01 -0000 All, The id is at version 3 now ... https://datatracker.ietf.org/doc/draft-irtf-samrg-sam-baseline-protocol/ Thanks, John -----Original Message----- From: irsg-bounces@irtf.org [mailto:irsg-bounces@irtf.org] On Behalf Of Thomas C. Schmidt Sent: Saturday, April 27, 2013 9:25 AM To: Internet Research Steering Group Cc: sam Subject: [irsg] IRSG Poll for draft-irtf-samrg-sam-baseline-protocol-02 Folks, SAMRG has completed work on the informational document draft-irtf-samrg-sam-baseline-protocol-02. Michael Welzl has performed the IRSG review and authors have updated accordingly, see http://trac.tools.ietf.org/group/irtf/trac/ticket/54. This mail initiates a 3 weeks IRSG poll following the IRSG review = process, see http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#Reviews. = The poll ends on May 18th. We need two "ready to publish" votes to progress the document. Cheers, Thomas --=20 Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 From waehlisch@ieee.org Sat Apr 27 14:38:21 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41721F85EE for ; Sat, 27 Apr 2013 14:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799, 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 7XfcD1pLp8BW for ; Sat, 27 Apr 2013 14:38:20 -0700 (PDT) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABAD21F8503 for ; Sat, 27 Apr 2013 14:38:20 -0700 (PDT) Envelope-to: sam@irtf.org Received: from e178059151.adsl.alicedsl.de ([85.178.59.151] helo=mw-PC.fritz.box) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UWCp0-0008iT-K0 for sam@irtf.org; Sat, 27 Apr 2013 23:38:18 +0200 Date: Sat, 27 Apr 2013 23:38:13 +0200 From: Matthias Waehlisch To: sam@irtf.org Message-ID: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sam@irtf.org Subject: [SAM] New Version Notification for draft-irtf-samrg-common-api-08.txt (fwd) X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:38:21 -0000 Folks, we published an update of the Common API draft, which includes editorial polishing following Tony's review. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net ---------- Forwarded message ---------- Date: Sat, 27 Apr 2013 14:35:55 -0700 From: internet-drafts@ietf.org To: Thomas Schmidt , Matthias Waehlisch , Stig Venaas , Thomas C. Schmidt Subject: New Version Notification for draft-irtf-samrg-common-api-08.txt A new version of I-D, draft-irtf-samrg-common-api-08.txt has been successfully submitted by Matthias Waehlisch and posted to the IETF repository. Filename: draft-irtf-samrg-common-api Revision: 08 Title: A Common API for Transparent Hybrid Multicast Creation date: 2013-04-27 Group: samrg Number of pages: 41 URL: http://www.ietf.org/internet-drafts/draft-irtf-samrg-common-api-08.txt Status: http://datatracker.ietf.org/doc/draft-irtf-samrg-common-api Htmlized: http://tools.ietf.org/html/draft-irtf-samrg-common-api-08 Diff: http://www.ietf.org/rfcdiff?url2=draft-irtf-samrg-common-api-08 Abstract: Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable, upper layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay, and grants access to the different multicast flavors. It proposes an abstract naming by multicast URIs and discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current multicast domains throughout the Internet. It reports on an implementation of the programming interface, including a service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group. The IETF Secretariat From prvs=822619329=schmidt@informatik.haw-hamburg.de Sat Apr 27 14:55:46 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3422B21F9822; Sat, 27 Apr 2013 14:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_RAND_LETTRS4=0.799, 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 IN05iDRn4ImS; Sat, 27 Apr 2013 14:55:45 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 0667021F9821; Sat, 27 Apr 2013 14:55:44 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 27 Apr 2013 23:55:44 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 1DAB310AE75B; Sat, 27 Apr 2013 23:55:44 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15919-03; Sat, 27 Apr 2013 23:55:43 +0200 (CEST) Received: from [192.168.178.33] (e178059151.adsl.alicedsl.de [85.178.59.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 213871066AEF; Sat, 27 Apr 2013 23:55:42 +0200 (CEST) Message-ID: <517C495A.6020802@informatik.haw-hamburg.de> Date: Sat, 27 Apr 2013 23:55:38 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Internet Research Steering Group Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: sam Subject: [SAM] IRSG Poll for draft-irtf-samrg-common-api-08 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:55:47 -0000 Folks, this call comes on behalf of the document shepherd John Buford. SAMRG has completed work on the experimental document draft-irtf-samrg-common-api-08. Lisandro Zambenedetti Granville and Tony Li have performed IRSG reviews and authors have updated accordingly, see http://trac.tools.ietf.org/group/irtf/trac/ticket/50. This mail initiates a 3 weeks IRSG poll following the IRSG review process, see http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#Reviews. The poll ends on May 18th. We need two "ready to publish" votes to progress the document. Lisandro, Tony: As you have already issued this vote, would you repeat to meet the formal IRSG precedures? Thanks, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From michawe@ifi.uio.no Sat Apr 27 22:23:24 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BE921F9487; Sat, 27 Apr 2013 22:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799, 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 uJiT5x835R5s; Sat, 27 Apr 2013 22:23:23 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 985EE21F8F0F; Sat, 27 Apr 2013 22:23:22 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UWK52-0003Ll-Ls; Sun, 28 Apr 2013 07:23:20 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UWK51-0005os-Bx; Sun, 28 Apr 2013 07:23:20 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_ED604941-6734-4505-81F6-29B9B644FE8A" Message-Id: <4B1FBAB9-36C6-42B5-B976-6A156C72E432@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Sun, 28 Apr 2013 07:23:18 +0200 References: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> To: Internet Research Steering Group X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 3994 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 92FB2BC922A2843A51E4F2D0B7CC4EB0E07084D3 X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 487 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: sam@irtf.org Subject: [SAM] Fwd: [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 05:23:24 -0000 --Apple-Mail=_ED604941-6734-4505-81F6-29B9B644FE8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I just noticed that somehow, irsg and samrg were dropped from the list = of recipients of this response, sorry Begin forwarded message: > From: Michael Welzl > Subject: Re: [irsg] IRSG review for = draft-irtf-samrg-sam-baseline-protocol-02 > Date: April 24, 2013 4:06:17 PM GMT+02:00 > To: Dr Mario Kolberg > Cc: sam , John Buford >=20 > Hi, >=20 > In line: >=20 >=20 > On 22. apr. 2013, at 12:36, Dr Mario Kolberg wrote: >=20 >> Hi Michael and All, >>=20 >> please find below our response to the IRSG review by Michael Welzl. >>=20 >> Best wishes, >> Mario & John >> =20 >>>=20 >>> General higher-level comments:=20 >>>=20 >>> 1) I found parts of the document very hard to read, sometimes = wondered if this is really necessary. >>>=20 >> The document is intended for an audience which does have a technical = background in the area of application layer multicasting and peer to = peer overlay protocols. We would expect readers unfamiliar with the = area to first go to more basic material. Perhaps many comments in the = review stem from the fact that the reviewer doesn=92t have this = familiarity. To help readers to get a better understanding we have added = references to introductory and background material as a starting point: >> J. Buford, H. Yu, E. K. Lua P2P Networking and Applications. Morgan = Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting). >> M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of = Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon). >> J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in: Encyclopedia = of Wireless and Mobile Communications. 2008. >>=20 > Good! > I would like to mention that, while I know very little about = application layer multicast, I do have some (outdated) P2P knowledge. = It's not really my field, but I have done a little bit of work on it and = also taught a lecture about it a few years ago (which even contained a = brief overview of Scribe, IIRC). So that made me think, someone like me = should at least be able to make some sense of the document - within = certain limits of course, as I know nothing about RELOAD, for example. >=20 >=20 >>> 2) In particular, P2PCast appears to be a rather complex algorithm = which is "sort of" described here... I doubt that the description in the = document will help most readers to really fully understand P2PCast, and = I wonder, is it necessary for this doc to try to really explain the = algorithm (when, in doing so, it can really only go half-way anyway)? = e.g., wouldn't it suffice to just keep the "Overview" (section 9.1) but = then point to [P2PCAST] for further details, and just list the necessary = facts? e.g., the JOIN procedure - do we have to know all these details = here, isn't it enough to e.g. list the reorganisation messages by name = and say that they're used in accordance with [P2PCAST]? >> The ID is written for a technical audience which is presumed to be = knowledgeable about RELOAD and P2P overlays and has some familiarity = with multicasting at the application layer. We provide summaries of = P2PCAST and SCRIBE since these two algorithms are well known in the ALM = research community, and are each representative of an important class of = ALM algorithms. If the reader needs more background, then they can go = to the reference papers and find it there. >> In our opinion, the inclusion of the essential features about each = algorithm is useful and should be in the ID. The level of detail = describes =93Scribe-like=94 and =93P2PCast-like=94 algorithms, and not = only Scribe and P2PCAST. Since the protocol we define is intended to = support a large variety of such algorithms. >>=20 >> This is done in other in other IDs and RFCs. For example, please = take a look at section 10 of the RELOAD ID which gives detailed = information about the Chord algorithm, but yet omits Chord details which = one would find in the original papers from MIT. If your comments were = followed, this Chord material should be removed from RELOAD spec. = Likewise see this id produced by the PPSP WG draft-ietf-ppsp-survey-04. = There are lots of other examples where important previously existing = algorithms are summarized in an ID. >=20 > Well. I'm not sure if the cases you compare here really are comparable = - the Chord text in the RELOAD ID is much longer, for a (it seems to me) = much simpler algorithm, and a survey is really a different case, I think = - its overall intention is different from a document like this one. But = I see your point about trying to convey the essential features right = here, and if you feel the text explains the essential bits and is = helpful, I'll trust you on this one, given my lack of expertise in = application-layer multicast. >=20 >=20 >>> 3) Another source of confusion: the Scribe algorithm description has = some pseudocode that I wasn't able to parse (maybe it refers to RELOAD = things?) Not all functions there seem to clearly relate to messages that = were described earlier. Even more confusing, the P2PCast algorithm = description doesn't have these pseudocode snippets, so the whole thing = appears inconsistent. Should it be everywhere? Should it be removed? If = it stays, some explanations are needed. It can't be up to the reader to = guess what e.g. "invokeMessageHandler" does, right?? (section 8.7). In = this particular section, I would also expect the text and/or pseudocode = to somehow draw a relationship to "push" (listed in fig. 3), but that's = not there... so what is this? >>=20 >> We agree that this pseudocode is more general and applies to both = algorithms. To avoid duplication, we have moved it from Section 8 to the = relevant subsections in Section 7. =20 >=20 > Fine. >=20 >>> 4) Structure: even if the two algorithms are only a part of the = whole thing you define, the text going with them feels a bit like "we've = set the stage, now we apply it - the messages you heard about before are = used like this & that with this & that algorithm". That's fine! But it = also gives the reader the feeling of that being "part 2", i.e. I think = it should be at the end, if that makes sense. >>>=20 >> Yes the algorithms are an application of the material in earlier = sections, but we don't agree that moving it to the end will help the = understanding of the draft.=20 >=20 > Fine. >=20 >>> 5) I also think that it would be better to move the examples = (section 12) to where you introduce the messages, the flow of which they = illustrate. First I have to imagine what an "INVITE" message flow could = look like, then I get complicated explanations of how INVITE is applied = in an algorithm that I can't fully understand from this text anyway, and = THEN I get a nice example illustrating an INVITE message flow... that's = not very helpful for the reader I think. e.g., when I read 7.2.3, I = wondered why the "peer_id" of the source peer is even needed in the = struct. By looking at the example, this would have become clear to me. >>>=20 >> The document is not meant to be a tutorial, hence the examples are = not first. The examples follow the definition of the messages so that = the message use is illustrated. If we moved the examples first, then = some other reviewer could then say =85 why are the examples shown before = the protocol messages are defined? It is not the purpose of the ID to = bootstrap the reader into basic knowledge of ALM and Peer to Peer = messaging. >>=20 > Fine. >=20 >>> 6) Speaking of the examples, what's the point of showing more peers = than you actually use in the example? Okay, I can understand that = perhaps you wanted to have the same number for all of them, but then you = could still remove P3 because it seems that you never use P3 for = anything in any of the examples. >>=20 >> We added these peers is to illustrate that 1) not all the peers in = the overlay have to be part of each ALM connection, and 2) the overlay = could have an arbitrary number of peers. >=20 > Well, even a total P2P nut like myself understands that without even = seeing P3, but whatever :-) >=20 >>> 7) Nits: >>>=20 >>> IANA Considerations: are you sure that there is nothing? e.g., how = would a new algorithm code be assigned? (section 11.4)=20 >>> - btw, why is the section called "Algorithm Codes" but then the text = talks about "Algorithm Types" ? >>>=20 >> There are no IANA considerations since this is to be an informational = RFC. >=20 > Ah, ok, sure - >=20 >>> 8) Some references (CASTRO2003, P2PCAST) need a space (I mean, " ") = after their first appearance.=20 >>> cut..... >> All these edits have been done and version 03 has been submitted.=20 >=20 > Fine, thanks! >=20 > Cheers, > Michael >=20 --Apple-Mail=_ED604941-6734-4505-81F6-29B9B644FE8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Michael Welzl = <michawe@ifi.uio.no>
Subject: = Re: [irsg] IRSG review for = draft-irtf-samrg-sam-baseline-protocol-02
Date: April 24, 2013 = 4:06:17 PM GMT+02:00
To: Dr Mario Kolberg <mko@cs.stir.ac.uk>
Cc: sam <sam@irtf.org>, John Buford <buford@samrg.org>
=
Hi,

In = line:


On 22. apr. 2013, at 12:36, = Dr Mario Kolberg wrote:

=20 =20
Hi Michael and All,

please find below our response to the IRSG review by Michael Welzl.

Best wishes,
Mario & John
 

General = higher-level comments:

1) I found parts of the = document very hard to read, sometimes wondered if this is really = necessary.

The document is intended for an audience which does have a technical background in the area of application layer multicasting and peer to peer overlay protocols.  We would = expect readers unfamiliar with the area to first go to more basic material. Perhaps many comments in the review stem from the fact that the reviewer doesn=92t have this familiarity. To help readers to get a better understanding we have added references to introductory and background material as a starting = point:

J. Buford, H. Yu, E. = K. Lua P2P Networking and Applications. Morgan Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting).
M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon).
J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in: Encyclopedia of Wireless and Mobile Communications. = 2008.

Good!
I would like to = mention that, while I know very little about application layer = multicast, I do have some (outdated) P2P knowledge. It's not really my = field, but I have done a little bit of work on it and also taught a = lecture about it a few years ago (which even contained a brief overview = of Scribe, IIRC). So that made me think, someone like me should at least = be able to make some sense of the document - within certain limits of = course, as I know nothing about RELOAD, for = example.


2) In particular, P2PCast appears to be = a rather complex algorithm which is "sort of" described here... I doubt that the description in the document will help most readers to really fully understand P2PCast, and I  wonder, = is it necessary for this doc to try to really explain the algorithm (when, in doing so, it can really only go half-way anyway)? e.g., wouldn't it suffice to just keep the "Overview" (section 9.1) but then point to [P2PCAST] for further details, and just list the necessary facts? e.g., the JOIN procedure - do we have to know all these details here, isn't it enough to e.g. list the reorganisation messages by name and say that they're used in accordance with [P2PCAST]?
The ID is written for a technical audience which is presumed to be knowledgeable about RELOAD and P2P overlays and has = some familiarity with multicasting at the application layer.  = We provide summaries of P2PCAST and SCRIBE since these two algorithms are well known in the ALM research community, and are each representative of an important class of ALM algorithms.  If = the reader needs more background, then they can go to the reference papers and find it there.

In our opinion, the inclusion of the essential features about each algorithm is useful and should be in the ID.  The level of detail describes  =93Scribe-like=94 and =93P2PCast-like=94 algorithms, and = not only Scribe and P2PCAST.  Since the protocol we define is = intended to support a large variety of such algorithms.

This is done in other in other IDs and RFCs.   For = example, please take a look at section 10 of the RELOAD ID which gives detailed information about the Chord algorithm, but yet omits Chord details which one would find in the original papers from MIT. If your comments were followed, this Chord material should be removed from RELOAD spec.      Likewise see this id = produced by the PPSP WG draft-ietf-ppsp-survey-04.  There are lots of other examples = where important previously existing algorithms are summarized in an = ID.

Well. I'm not sure = if the cases you compare here really are comparable - the Chord text in = the RELOAD ID is much longer, for a (it seems to me) much simpler = algorithm, and a survey is really a different case, I think - its = overall intention is different from a document like this one. But I see = your point about trying to convey the essential features right here, and = if you feel the text explains the essential bits and is helpful, I'll = trust you on this one, given my lack of expertise in application-layer = multicast.


=20
3) Another source of confusion: the = Scribe algorithm description has some pseudocode that I wasn't able to parse (maybe it refers to RELOAD things?) Not all functions there seem to clearly relate to messages that were described earlier. Even more confusing, the P2PCast algorithm description doesn't have these pseudocode snippets, so the whole thing appears inconsistent. Should it be everywhere? Should it be removed? If it stays, some explanations are needed. It can't be up to the reader to guess what e.g. "invokeMessageHandler" does, right?? (section 8.7). In this particular section, I would also expect the text and/or pseudocode to somehow draw a relationship to "push" (listed in fig. 3), but that's not there... so what is this?

 We agree that this pseudocode is more general and = applies to both algorithms. To avoid duplication, we have moved it from Section 8 to the relevant subsections in Section = 7.  =

Fine.

4) Structure: = even if the two algorithms are only a part of the whole thing you define, the text going with them feels a bit like "we've set the stage, now we apply it - the messages you heard about before are used like this & that with this & that algorithm". That's fine! But it also gives the reader the feeling of that being "part 2", i.e. I think it should be at the end, if that makes = sense.

Yes the algorithms are an application of the material in earlier sections, but we don't agree that moving it to the end will help the understanding of the draft. =

Fine.

=20

5) I also think = that it would be better to move the examples (section 12) to where you introduce the messages, the flow of which they illustrate. First I have to imagine what an "INVITE" message flow could look like, then I get complicated explanations of how INVITE is applied in an algorithm that I can't fully understand from this text anyway, and THEN I get a nice example illustrating an INVITE message flow... that's not very helpful for the reader I think.  = e.g., when I read 7.2.3, I wondered why the "peer_id" of the source peer is even needed in the struct. By looking at the example, this would have become clear to me.

The document is not meant to be = a tutorial, hence the examples are not first.  The examples follow the definition of the messages so that the message use is illustrated.  If we moved the examples first, then some = other reviewer could then say =85 why are the examples = shown before the protocol messages are defined? It is not the purpose of the ID to bootstrap the reader into basic knowledge of ALM and Peer to Peer messaging. =

Fine.

6) Speaking of the examples, = what's the point of showing more peers than you actually use in the example? Okay, I can understand that perhaps you wanted to have the same number for all of them, but then you could still remove P3 because it seems that you never use P3 for anything in any of the examples.

We added these peers is to illustrate that 1) not all the peers in the overlay have to be part of each ALM connection, and 2) the overlay could have an arbitrary number of = peers.

Well, even a total P2P nut = like myself understands that without even seeing P3, but = whatever  :-)

7) = Nits:

IANA Considerations: are you = sure that there is nothing? e.g., how would a new algorithm code be assigned?   (section 11.4)
- btw, why is the section called "Algorithm Codes" but then the text talks about "Algorithm Types" ?

There are no IANA considerations since this is to be an informational RFC.

Ah, ok, sure = -

8) Some references (CASTRO2003, P2PCAST) need a space (I mean, " ") after their first appearance.
cut.....

All these edits have been done and version 03 has been = submitted.

Fine, = thanks!

Cheers,
Michael

<= /div>

= --Apple-Mail=_ED604941-6734-4505-81F6-29B9B644FE8A-- From tony.li@tony.li Sat Apr 27 16:19:32 2013 Return-Path: X-Original-To: sam@ietfa.amsl.com Delivered-To: sam@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BD521F98F8 for ; Sat, 27 Apr 2013 16:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.638 X-Spam-Level: X-Spam-Status: No, score=-99.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_RAND_LETTRS4=0.799, 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 0cV5hgUem7uB for ; Sat, 27 Apr 2013 16:19:31 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id A135E21F98E8 for ; Sat, 27 Apr 2013 16:19:31 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta12.emeryville.ca.mail.comcast.net with comcast id VAfX1l0051u4NiLACBKXTb; Sat, 27 Apr 2013 23:19:31 +0000 Received: from [192.168.2.111] ([98.248.36.188]) by omta21.emeryville.ca.mail.comcast.net with comcast id VBKV1l00R43ZcXW8hBKVR3; Sat, 27 Apr 2013 23:19:30 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tony Li In-Reply-To: <517C495A.6020802@informatik.haw-hamburg.de> Date: Sat, 27 Apr 2013 16:19:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <517C495A.6020802@informatik.haw-hamburg.de> To: "Thomas C. Schmidt" X-Mailer: Apple Mail (2.1503) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367104771; bh=br6l30LfQ1fkq29gJZ8GzFnxeoO8xRLnuunid57CQrI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=ZGX7cftlG785Aafd3Eo1MJPnHaZ9APv7kjdGzaN44jpfmpdAC6dNq5zNVR0x3gCUc OhK6BTDNsZl9N70W1TjXO20OCNxt12gqutC2Ho1uqkcYABXE9yYZlpX3imS4X845OT QLwBEL831CQqujaRmbftoHswa/l855+hU3g6hZig/jNRBFUwb00ZG6RmOgyOysXo2p 41lW9OfUGC4wSAPwi3hEehG5h9qbMlV/WblYKQq31KjcbM2kZTxI8g8z6D6pskSuZv OmaAkVg8/+2WBBuE3r4v6WDOJJ8GZiSl31a3j+y4qvmSG04nzKmkwnPLp+hB2rtfZJ yNtLQTSDVqNyw== X-Mailman-Approved-At: Sun, 28 Apr 2013 12:02:51 -0700 Cc: sam , Internet Research Steering Group Subject: Re: [SAM] [irsg] IRSG Poll for draft-irtf-samrg-common-api-08 X-BeenThere: sam@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "For use by members of the Scalable Adaptive Multicast \(SAM\) RG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 23:19:32 -0000 On Apr 27, 2013, at 2:55 PM, "Thomas C. Schmidt" = wrote: > We need two "ready to publish" votes to progress the document. >=20 > Lisandro, Tony: As you have already issued this vote, would you repeat = to meet the formal IRSG precedures? This document is ready to publish. Tony