From prvs=7310067af=schmidt@informatik.haw-hamburg.de Sat Jan 26 15:39:07 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 997EC21F8940 for ; Sat, 26 Jan 2013 15:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.55 X-Spam-Level: X-Spam-Status: No, score=-98.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_62=0.6, MANGLED_LIST=2.3, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIId+howTO2r for ; Sat, 26 Jan 2013 15:39:06 -0800 (PST) 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 37B3621F893E for ; Sat, 26 Jan 2013 15:39:05 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 27 Jan 2013 00:39:03 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id EB2E91066AE3; Sun, 27 Jan 2013 00:39:03 +0100 (CET) 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 20881-05; Sun, 27 Jan 2013 00:39:03 +0100 (CET) Received: from [192.168.178.33] (g231104150.adsl.alicedsl.de [92.231.104.150]) (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 2610E1066AE2; Sun, 27 Jan 2013 00:39:03 +0100 (CET) Message-ID: <51046914.8030700@informatik.haw-hamburg.de> Date: Sun, 27 Jan 2013 00:39:00 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Buford , Dr Mario Kolberg 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] Review of draft-irtf-samrg-sam-baseline-protocol 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, 26 Jan 2013 23:39:07 -0000 Dear John and Mario, finally I can contribute my review to your draft. In general, this document is interesting and in good shape. I found a number of editorial and presentation issues, though: General issues: * s/a ALM/an ALM/ * Please provide captions to figures * Please reference figures unambiguously by numbers, not by positions (e.g., "figure above/below") * As this document is intended to be informational, normative references are inappropriate, I believe. Rather change all references to informational ... Detailed comments: [Section 1, 1st enumeration:] s/trees connect nodes over global internet/trees connect nodes over the global Internet [Section 1, 2nd enumeration:] epending on initial application parameters or application class*es* [Section 2.3] additional roles such as connection relays, super nodes, NAT traversal *assistance* [Section 3.3] "We use RELOAD [I-D.ietf-p2psip-base] as the distibuted hash table (DHT)" ... I would RELOAD not coin a DHT, rather a generic P2P overlay protocol ... [Section 4, 2nd point of 1st enumeration:] ... store diagnostic information about the operation of tree*s* ... in addition: s/lost packet rate/packet loss rate [Section 5, 4th point of 1st enumeration:] Defines the Resource Name used to hash to the Resource ID *that determines* where the kind is stored [Section 6, 4th para:] s/Its main advantage is use of the overlay routing mechanism for routing both control and data messages./Its main advantage is use of the overlay for routing both control and data messages. [Section 6, enumeration point 5, "ASM tree":] This describes a specific bidirectional flooding mechanism on shared trees. Is this intended as such? This should be clarified ... [Section 7 - in general:] This section explains the protocol handshakes, but does not display any sequence diagrams. Corresponding diagrams are in Section 12 - please reference or move ... [Section 7.1, 1st para:] Refers to "I-D.irtf-sam-h]ybrid-overlay-framework" in a somewhat vague manner - maybe the key argument should be inlined to make the document more consistent? [Section 7.1, 2nd para:] mentiones "SAM requirements draft" without referencing. [Section 7.1, Dictionary data structure:] The Dictionary data structure displayed in this draft differs from the RELOAD Dictionary data structure - is this intended? Is this useful? [Section 7.2.1, 1st para:] "... of group_id is that the peer with peer id closest to and less than the group_id is the root of the tree." -> this seems very specific to CORD, is this intended as such? Maybe a more generic formulation is useful? [Section 7.2.1, 3rd para:] This paragraph is very hard to parse ... please explain more carefully what "create tree" does. [Section 7.2.3, 1st para:] "If successful, the peer_id is notified ..." -> peer_id is a number, who is notified? [Section 7.2.3, 2nd para:] "RELOAD is a client server protocol" - you mean to say "RELOAD is a request-response protocol" ? [Section 7.2.6, 1st para:] "the negotiation of options between the two peers." - I haven't seen any explanation of this negotiation mechanism ?? In general: The use, syntax and semantic of options might be worth to specify/illustrate, at least in the specific example sections (Scribe, P2PCast) ... (I suppose, options are always algorithm-specific). [Section 7.2.17, "max_tree_data":] this is a global quantity commonly unavailable to any P2P overlay node ... I wonder what this is based on? Is this an optional value supplied if known? [Section 7.2.19, "PushResponse:] Who sends this - the neighboring peer or the receiver to the sender? [Section 9:] A message table as supplied in Section 8 should be helpful. [Section 9.3, 1st para after enumeration:] "P2Pcast uses defined messages ..." This para is fairly unclear to me - clarify? [Section 16:] This seems to contradict Section 14?? It would be good to provide a polished update prior to moving this ID ... Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Scienc"es 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 Jan 28 14:03:37 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 240C021F85A0; Mon, 28 Jan 2013 14:03:37 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG+CiICiWIYe; Mon, 28 Jan 2013 14:03:36 -0800 (PST) Received: from mail1.rz.htw-berlin.de (mail1.rz.htw-berlin.de [141.45.10.101]) by ietfa.amsl.com (Postfix) with ESMTP id CA5EB21F8507; Mon, 28 Jan 2013 14:03:32 -0800 (PST) Envelope-to: sam@irtf.org, irsg@irtf.org Received: from e178058171.adsl.alicedsl.de ([85.178.58.171] helo=mw-PC.fritz.box) by mail1.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Tzwnb-0008vx-BC; Mon, 28 Jan 2013 23:03:31 +0100 Date: Mon, 28 Jan 2013 23:03:25 +0100 From: Matthias Waehlisch To: Lisandro Zambenedetti Granville In-Reply-To: <89A23CF2-E49B-4D6D-983F-7E03A14C34D6@inf.ufrgs.br> Message-ID: References: <50134BFD.4060103@alcatel-lucent.com> <07f701cd7e33$7296cdd0$57c46970$@org> <89A23CF2-E49B-4D6D-983F-7E03A14C34D6@inf.ufrgs.br> 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: buford@irtf.org Cc: sam@irtf.org, 'Internet Research Steering Group' Subject: Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-common-api-06 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, 28 Jan 2013 22:03:37 -0000 Dear Lisandro, sorry for the late reply! Many thanks for this very careful review! We included your comments and some additional clarifications. The new version is available at http://tools.ietf.org/html/draft-irtf-samrg-common-api-07 Thanks again 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 On Fri, 28 Dec 2012, Lisandro Zambenedetti Granville wrote: > All, > > I reviewed the draft-irtf-samrg-common-api-06.txt. There are some editorial improvements that can be made. In order to point them more clearly, I've used an annotated PDF file attached to this message. > > Regards, > > Lisandro > > From mko@cs.stir.ac.uk Wed Jan 30 03:44:13 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 5F7BF21F8840 for ; Wed, 30 Jan 2013 03:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW3oTQRacCSM for ; Wed, 30 Jan 2013 03:44:11 -0800 (PST) Received: from bannock.stir.ac.uk (bannock.stir.ac.uk [139.153.12.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0757221F883B for ; Wed, 30 Jan 2013 03:44:09 -0800 (PST) Received: from smtp5.stir.ac.uk ([139.153.13.214]) by bannock.stir.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0W5A-0000wI-Sa; Wed, 30 Jan 2013 11:44:00 +0000 Received: from d253090.cs.stir.ac.uk ([139.153.253.90]) by smtp5.stir.ac.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1U0W5A-0001Bg-IW; Wed, 30 Jan 2013 11:44:00 +0000 Message-ID: <5109077B.3030609@cs.stir.ac.uk> Date: Wed, 30 Jan 2013 11:43:55 +0000 From: Dr Mario Kolberg User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <20130130112623.22943.55076.idtracker@ietfa.amsl.com> In-Reply-To: <20130130112623.22943.55076.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130130112623.22943.55076.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080508060706040601080909" X-stir.ac.uk-MailScanner-ID: 1U0W5A-0000wI-Sa X-stir.ac.uk-MailScanner: Found to be clean Cc: sam Subject: [SAM] Fwd: New Version Notification for draft-irtf-samrg-sam-baseline-protocol-02.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: Wed, 30 Jan 2013 11:44:13 -0000 This is a multi-part message in MIME format. --------------080508060706040601080909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Thomas, many thanks again for your helpful comments. We have updated the SAM Baseline draft according your comments and uploaded a new version (02) of the draft. Links to the new version are near the end of this email. Details of the changes made are listed below in-line with your comments. Mario & John > General issues: > > * s/a ALM/an ALM/ > * Please provide captions to figures > * Please reference figures unambiguously by numbers, not by positions > (e.g., "figure above/below") > * As this document is intended to be informational, normative > references are inappropriate, I believe. Rather change all references > to informational ... all fixed. > Detailed comments: > > [Section 1, 1st enumeration:] s/trees connect nodes over global > internet/trees connect nodes over the global Internet > [Section 1, 2nd enumeration:] epending on initial application > parameters or application class*es* > [Section 2.3] additional roles such as connection relays, super nodes, > NAT traversal *assistance* > [Section 3.3] "We use RELOAD [I-D.ietf-p2psip-base] as the distibuted > hash table (DHT)" ... I would RELOAD not coin a DHT, rather a generic > P2P overlay protocol ... > [Section 4, 2nd point of 1st enumeration:] ... store diagnostic > information about the operation of tree*s* ... > in addition: s/lost packet rate/packet loss rate > [Section 5, 4th point of 1st enumeration:] Defines the Resource Name > used to hash to the Resource ID *that determines* where the kind is > stored > [Section 6, 4th para:] s/Its main advantage is use of the overlay > routing mechanism for routing both control and data messages./Its main > advantage is use of the overlay for routing both control and data > messages. all fixed. > [Section 6, enumeration point 5, "ASM tree":] This describes a > specific bidirectional flooding mechanism on shared trees. Is this > intended as such? This should be clarified ... ASM and SSM have been added to the Definition section. > [Section 7 - in general:] This section explains the protocol > handshakes, but does not display any sequence diagrams. Corresponding > diagrams are in Section 12 - please reference or move ... a reference has now been added. > [Section 7.1, 1st para:] Refers to > "I-D.irtf-sam-h]ybrid-overlay-framework" in a somewhat vague manner - > maybe the key argument should be inlined to make the document more > consistent? This reference actually referred to an older version of this draft. Reference removed and reworded. > [Section 7.1, 2nd para:] mentiones "SAM requirements draft" without > referencing. reference added. > [Section 7.1, Dictionary data structure:] The Dictionary data > structure displayed in this draft differs from the RELOAD Dictionary > data structure - is this intended? Is this useful? This links to a discussion we had with Marc some time ago. Dictionary is not defined as a datatype in RELOAD, but as a model (7.2.3). Thus we have defined Dictionary in the draft. However, we now use the DictionaryEntry type defined in the RELOAD v24 draft. > [Section 7.2.1, 1st para:] "... of group_id is that the peer with > peer id closest to and less than the group_id is the root of the > tree." -> this seems very specific to CORD, is this intended as such? > Maybe a more generic formulation is useful? slightly reworded. The text states that this is just a common use - thus not always. > [Section 7.2.1, 3rd para:] This paragraph is very hard to parse ... > please explain more carefully what "create tree" does. reworded. > [Section 7.2.3, 1st para:] "If successful, the peer_id is notified > ..." -> peer_id is a number, who is notified? reworded. > [Section 7.2.3, 2nd para:] "RELOAD is a client server protocol" - you > mean to say "RELOAD is a request-response protocol" ? reworded. > [Section 7.2.6, 1st para:] "the negotiation of options between the two > peers." - I haven't seen any explanation of this negotiation mechanism ?? The previous sentence mentions parameter negotiation and thus we feel this is ok. > In general: The use, syntax and semantic of options might be worth to > specify/illustrate, at least in the specific example sections (Scribe, > P2PCast) ... (I suppose, options are always algorithm-specific). Section 7 contains syntax and semantic of options. Doing it again seems repetitive. > [Section 7.2.17, "max_tree_data":] this is a global quantity commonly > unavailable to any P2P overlay node ... I wonder what this is based > on? Is this an optional value supplied if known? explanation added. NodeQuery can be used to crawl all the nodes in an ALM tree. Using the tree_data list in the NodeStatistics, the node can populate the max_tree_data field. This is intended to support monitoring, algorithm design, and general experimentation with ALM in RELOAD. > [Section 7.2.19, "PushResponse:] Who sends this - the neighboring peer > or the receiver to the sender? reworded. > [Section 9:] A message table as supplied in Section 8 should be helpful. table added. > [Section 9.3, 1st para after enumeration:] "P2Pcast uses defined > messages ..." This para is fairly unclear to me - clarify? reworded. [Section 16:] This seems to contradict Section 14?? Clarified in Section 14 and Section 16 removed. -------- Original Message -------- Subject: New Version Notification for draft-irtf-samrg-sam-baseline-protocol-02.txt Date: Wed, 30 Jan 2013 03:26:23 -0800 From: internet-drafts@ietf.org To: mkolberg@ieee.org CC: buford@avaya.com A new version of I-D, draft-irtf-samrg-sam-baseline-protocol-02.txt has been successfully submitted by Mario Kolberg and posted to the IETF repository. Filename: draft-irtf-samrg-sam-baseline-protocol Revision: 02 Title: Application Layer Multicast Extensions to RELOAD Creation date: 2013-01-29 WG ID: samrg Number of pages: 42 URL: http://www.ietf.org/internet-drafts/draft-irtf-samrg-sam-baseline-protocol-02.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-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-irtf-samrg-sam-baseline-protocol-02 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.2890 / Virus Database: 2639/6051 - Release Date: 01/22/13 Internal Virus Database is out of date. -- 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. --------------080508060706040601080909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Thomas,

many thanks again for your helpful comments. We have updated the SAM Baseline draft according your comments and uploaded a new version (02) of the draft. Links to the new version are near the end of this email. Details of the changes made are listed below in-line with your comments.

Mario & John

General issues:

 * s/a ALM/an ALM/
 * Please provide captions to figures
 * Please reference figures unambiguously by numbers, not by positions (e.g., "figure above/below")
 * As this document is intended to be informational, normative references are inappropriate, I believe. Rather change all references to informational ...
all fixed.
Detailed comments:

[Section 1, 1st enumeration:] s/trees connect nodes over global internet/trees connect nodes over the global Internet
[Section 1, 2nd enumeration:] epending on initial application parameters or application class*es*
[Section 2.3] additional roles such as connection relays, super nodes, NAT traversal *assistance*
[Section 3.3] "We use RELOAD [I-D.ietf-p2psip-base] as the distibuted hash table (DHT)" ... I would RELOAD not coin a DHT, rather a generic P2P overlay protocol ...
[Section 4, 2nd point of 1st enumeration:] ... store diagnostic information about the operation of tree*s* ...
    in addition: s/lost packet rate/packet loss rate
[Section 5, 4th point of 1st enumeration:] Defines the Resource Name used to hash to the Resource ID *that determines* where the kind is stored
[Section 6, 4th para:] s/Its main advantage is use of the overlay routing mechanism for routing both control and data messages./Its main advantage is use of the overlay for routing both control and data messages.
all fixed.
[Section 6, enumeration point 5, "ASM tree":] This describes a specific bidirectional flooding mechanism on shared trees. Is this intended as such? This should be clarified ...
ASM and SSM have been added to the Definition section.
[Section 7 - in general:] This section explains the protocol handshakes, but does not display any sequence diagrams. Corresponding diagrams are in Section 12 - please reference or move ...
a reference has now been added.
[Section 7.1, 1st para:] Refers to "I-D.irtf-sam-h]ybrid-overlay-framework" in a somewhat vague manner - maybe the key argument should be inlined to make the document more consistent?
This reference actually referred to an older version of this draft. Reference removed and reworded.
[Section 7.1, 2nd para:] mentiones "SAM requirements draft" without referencing.
reference added.
[Section 7.1, Dictionary data structure:] The Dictionary data structure displayed in this draft differs from the RELOAD Dictionary data structure - is this intended? Is this useful?
This links to a discussion we had with Marc some time ago. Dictionary is not defined as a datatype in RELOAD, but as a model (7.2.3). Thus we have defined Dictionary in the draft. However, we now use the DictionaryEntry type defined in the RELOAD v24 draft.
[Section 7.2.1, 1st para:] "...  of group_id is that the peer with peer id closest to and less than the group_id is the root of the tree." -> this seems very specific to CORD, is this intended as such? Maybe a more generic formulation is useful?
slightly reworded. The text states that this is just a common use - thus not always.
[Section 7.2.1, 3rd para:] This paragraph is very hard to parse ... please explain more carefully what "create tree" does.
reworded.
[Section 7.2.3, 1st para:] "If successful, the peer_id is notified ..." -> peer_id is a number, who is notified?
reworded.
[Section 7.2.3, 2nd para:] "RELOAD is a client server protocol" - you mean to say "RELOAD is a request-response protocol" ?
reworded.
[Section 7.2.6, 1st para:] "the negotiation of options between the two peers." - I haven't seen any explanation of this negotiation mechanism ??
The previous sentence mentions parameter negotiation and thus we feel this is ok.
In general: The use, syntax and semantic of options might be worth to specify/illustrate, at least in the specific example sections (Scribe, P2PCast) ... (I suppose, options are always algorithm-specific).
Section 7 contains syntax and semantic of options. Doing it again seems repetitive.
[Section 7.2.17, "max_tree_data":] this is a global quantity commonly unavailable to any P2P overlay node ... I wonder what this is based on? Is this an optional value supplied if known?
explanation added. NodeQuery can be used to crawl all the nodes in an ALM tree.
Using the tree_data list in the NodeStatistics, the node can populate the max_tree_data field.
This is intended to support monitoring, algorithm design, and general
experimentation with ALM in RELOAD.
[Section 7.2.19, "PushResponse:] Who sends this - the neighboring peer or the receiver to the sender?
reworded.
[Section 9:] A message table as supplied in Section 8 should be helpful.
table added.
[Section 9.3, 1st para after enumeration:] "P2Pcast uses defined messages ..." This para is fairly unclear to me - clarify?
reworded.
[Section 16:] This seems to contradict Section 14??
 
Clarified in Section 14 and Section 16 removed.


-------- Original Message --------
Subject: New Version Notification for draft-irtf-samrg-sam-baseline-protocol-02.txt
Date: Wed, 30 Jan 2013 03:26:23 -0800
From: internet-drafts@ietf.org
To: mkolberg@ieee.org
CC: buford@avaya.com 


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

Filename:	 draft-irtf-samrg-sam-baseline-protocol
Revision:	 02
Title:		 Application Layer Multicast Extensions to RELOAD
Creation date:	 2013-01-29
WG ID:		 samrg
Number of pages: 42
URL:             http://www.ietf.org/internet-drafts/draft-irtf-samrg-sam-baseline-protocol-02.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-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-irtf-samrg-sam-baseline-protocol-02

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.2890 / Virus Database: 2639/6051 - Release Date: 01/22/13
Internal Virus Database is out of date.


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.
--------------080508060706040601080909--