Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02

[Michael Welzl <[e-mail]>]

Not sure that's needed?!
http://www.ietf.org/iesg/informational-vs-experimental.html doesn't say anything about requiring an implementation, unless I missed it

Cheers,
Michael


On May 1, 2013, at 2:39 PM, "Buford, John F (John)" <[e-mail]> wrote:

> Michael,
> 
> Thanks for your review.
> 
> We didn't have it as experimental since it doesn't report on an implementation.
> 
> John
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Welzl
> Sent: Wednesday, May 01, 2013 5:38 AM
> To: Thomas C. Schmidt; Internet Research Steering Group; [e-mail]
> Subject: Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02
> 
> Hi,
> 
> Yes.
> 
> One (non-blocking) question: why is this intended as Informational, and not Experimental? The latter would seem more appropriate to me.
> 
> Cheers,
> Michael
> 
> 
> On Apr 28, 2013, at 10:00 AM, Thomas C. Schmidt <[e-mail]> wrote:
> 
>> Hi Michael,
>> 
>> this means a "ready to publish" vote?
>> 
>> Viele Grüße
>> 
>> Thomas
>> 
>> On 28.04.2013 07:23, Michael Welzl wrote:
>>> 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 <[e-mail] 
>>>> <mailto:[e-mail]>>
>>>> *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 <[e-mail] 
>>>> <mailto:[e-mail]>>
>>>> *Cc: *sam <[e-mail] <mailto:[e-mail]>>, John Buford 
>>>> <[e-mail] <mailto:[e-mail]>>
>>>> 
>>>> Hi,
>>>> 
>>>> In line:
>>>> 
>>>> 
>>>> On 22. apr. 2013, at 12:36, Dr Mario Kolberg wrote:
>>>> 
>>>>> 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.
>>>>> 
>>>> 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 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.
>>>> 
>>>> 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?
>>>>> 
>>>>> 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.
>>>> 
>>>>>> 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.
>>>>> 
>>>> 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
>>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> SAM mailing list
>>> [e-mail]
>>> http://www.irtf.org/mailman/listinfo/sam
>>> 
>> 
>> --
>> 
>> 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: [phone] °
>> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °
> 
> _______________________________________________
> SAM mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/sam