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.