[SAM] Review of draft-irtf-samrg-sam-baseline-protocol

["Thomas C. Schmidt" <[e-mail]>]

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: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °