From michawe@ifi.uio.no Wed May 1 02:38:06 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 C074121F875C; Wed, 1 May 2013 02:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, 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 ro3A-PPI7ByH; Wed, 1 May 2013 02:38:02 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id C8EA821F8BCC; Wed, 1 May 2013 02:38:01 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1UXTU8-0005Ho-1Z; Wed, 01 May 2013 11:38:00 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UXTU7-0001A9-5k; Wed, 01 May 2013 11:37:59 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: <517CD713.3060006@informatik.haw-hamburg.de> Date: Wed, 1 May 2013 11:37:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no> References: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> <4B1FBAB9-36C6-42B5-B976-6A156C72E432@ifi.uio.no> <517CD713.3060006@informatik.haw-hamburg.de> To: "Thomas C. Schmidt" , Internet Research Steering Group , "sam@irtf.org" X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 7 sum msgs/h 4 total rcpts 4041 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 69590DBC4C95ACF8E90823DF66F0223735CE96AF X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 492 max/h 8 blacklist 0 greylist 0 ratelimit 0 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, 01 May 2013 09:38:06 -0000 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 = wrote: > Hi Michael, >=20 > this means a "ready to publish" vote? >=20 > Viele Gr=FC=DFe >=20 > Thomas >=20 > On 28.04.2013 07:23, Michael Welzl wrote: >> Hi, >>=20 >> I just noticed that somehow, irsg and samrg were dropped from the = list >> of recipients of this response, sorry >>=20 >> Begin forwarded message: >>=20 >>> *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 >>>>> General higher-level comments: >>>>>=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: >>>>=20 >>>> 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 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. >>>>=20 >>>> In our opinion, the inclusion of the essential features about each >>>> algorithm is useful and should be in the ID. The level of >>>> detaildescribes =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 >>> 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 >>> 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 = sothat >>>> the message use is illustrated. If we moved the examples first, = then >>>> some other reviewer could then say =85 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. >>>>=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) >>>>> - 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. >>>>> cut..... >>>>>=20 >>>> All these edits have been done and version 03 has been submitted. >>>=20 >>> Fine, thanks! >>>=20 >>> Cheers, >>> Michael >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> SAM mailing list >> SAM@irtf.org >> http://www.irtf.org/mailman/listinfo/sam >>=20 >=20 > --=20 >=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 buford@avaya.com Wed May 1 05:40:12 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 7155121F99ED; Wed, 1 May 2013 05:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 YrlHrxtW9JjW; Wed, 1 May 2013 05:40:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6821F9AED; Wed, 1 May 2013 05:39:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAJELgVGHCzI1/2dsb2JhbABSFoJQITa/F30WdIIfAQEBAQIBAQEBDwZTAwQCBQUHBAIBCA0BAwMBAQEBCh0HJwsUCQgCBAENBQgBCw6HZAYBC6NymwUXjDmBHYESDyIHBoJpYQOIXYNIkTdPhQuFHYMNgic X-IronPort-AV: E=Sophos;i="4.87,588,1363147200"; d="scan'208";a="7510310" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 May 2013 08:39:15 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 May 2013 08:35:52 -0400 Received: from AZ-US1EXMB02.global.avaya.com ([fe80::c01d:740:c927:8888]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Wed, 1 May 2013 08:39:13 -0400 From: "Buford, John F (John)" To: Michael Welzl , "Thomas C. Schmidt" , Internet Research Steering Group , "sam@irtf.org" Thread-Topic: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02 Thread-Index: AQHORk+Zxp8w5MItGEyaq06L/grZRJjwRPwQ Date: Wed, 1 May 2013 12:39:13 +0000 Message-ID: <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com> References: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> <4B1FBAB9-36C6-42B5-B976-6A156C72E432@ifi.uio.no> <517CD713.3060006@informatik.haw-hamburg.de> <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no> In-Reply-To: <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 01 May 2013 12:40:12 -0000 Michael, Thanks for your review. We didn't have it as experimental since it doesn't report on an implementat= ion. John -----Original Message----- From: sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] On Behalf Of Micha= el Welzl Sent: Wednesday, May 01, 2013 5:38 AM To: Thomas C. Schmidt; Internet Research Steering Group; sam@irtf.org Subject: Re: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-pro= tocol-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 wrote: > Hi Michael, >=20 > this means a "ready to publish" vote? >=20 > Viele Gr=FC=DFe >=20 > Thomas >=20 > On 28.04.2013 07:23, Michael Welzl wrote: >> Hi, >>=20 >> I just noticed that somehow, irsg and samrg were dropped from the=20 >> list of recipients of this response, sorry >>=20 >> Begin forwarded message: >>=20 >>> *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 >>> > >>>=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 >>>>> General higher-level comments: >>>>>=20 >>>>> 1) I found parts of the document very hard to read, sometimes=20 >>>>> wondered if this is really necessary. >>>>>=20 >>>> The document is intended for an audience which does have a=20 >>>> technical background in the area of application layer multicasting=20 >>>> and peer to peer overlay protocols. We would expect readers=20 >>>> unfamiliar with the area to first go to more basic material.=20 >>>> Perhaps many comments in the review stem from the fact that the=20 >>>> reviewer doesn't have this familiarity. To help readers to get a=20 >>>> better understanding we have added references to introductory and=20 >>>> background material as a starting point: >>>>=20 >>>> J. Buford, H. Yu, E. K. Lua P2P Networking and Applications. Morgan=20 >>>> Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting). >>>> M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of=20 >>>> Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon). >>>> J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in:=20 >>>> Encyclopedia of Wireless and Mobile Communications. 2008. >>>>=20 >>> Good! >>> I would like to mention that, while I know very little about=20 >>> 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=20 >>> and also taught a lecture about it a few years ago (which even=20 >>> contained a brief overview of Scribe, IIRC). So that made me think,=20 >>> someone like me should at least be able to make some sense of the=20 >>> document - within certain limits of course, as I know nothing about=20 >>> RELOAD, for example. >>>=20 >>>=20 >>>>> 2) In particular, P2PCast appears to be a rather complex algorithm=20 >>>>> which is "sort of" described here... I doubt that the description=20 >>>>> in the document will help most readers to really fully understand=20 >>>>> P2PCast, and I wonder, is it necessary for this doc to try to=20 >>>>> really explain the algorithm (when, in doing so, it can really=20 >>>>> only go half-way anyway)? e.g., wouldn't it suffice to just keep=20 >>>>> the "Overview" (section 9.1) but then point to [P2PCAST] for=20 >>>>> further details, and just list the necessary facts? e.g., the JOIN=20 >>>>> 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=20 >>>>> in accordance with [P2PCAST]? >>>> The ID is written for a technical audience which is presumed to be=20 >>>> knowledgeable about RELOAD and P2P overlays and has somefamiliarity=20 >>>> with multicasting at the application layer. We provide summaries of=20 >>>> P2PCAST and SCRIBE since these two algorithms are well known in the=20 >>>> ALM research community, and are each representative of an important=20 >>>> class of ALM algorithms. If the reader needs more background, then=20 >>>> they can go to thereference papers and find it there. >>>>=20 >>>> In our opinion, the inclusion of the essential features about each=20 >>>> algorithm is useful and should be in the ID. The level of=20 >>>> detaildescribes "Scribe-like" and "P2PCast-like" algorithms, and=20 >>>> not only Scribe and P2PCAST. Since the protocol we define is=20 >>>> 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=20 >>>> information about the Chord algorithm, but yet omits Chord details=20 >>>> which one would find in the original papers from MIT. If your=20 >>>> 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=20 >>>> important previously existing algorithms are summarized in an ID. >>>=20 >>> Well. I'm not sure if the cases you compare here really are=20 >>> 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,=20 >>> I think - its overall intention is different from a document like=20 >>> this one. But I see your point about trying to convey the essential=20 >>> features right here, and if you feel the text explains the essential=20 >>> bits and is helpful, I'll trust you on this one, given my lack of=20 >>> expertise in application-layer multicast. >>>=20 >>>=20 >>>>> 3) Another source of confusion: the Scribe algorithm description=20 >>>>> has some pseudocode that I wasn't able to parse (maybe it refers=20 >>>>> to RELOAD things?) Not all functions there seem to clearly relate=20 >>>>> to messages that were described earlier. Even more confusing, the=20 >>>>> P2PCast algorithm description doesn't have these pseudocode=20 >>>>> snippets, so the whole thing appears inconsistent. Should it be=20 >>>>> everywhere? Should it be removed? If it stays, some explanations=20 >>>>> are needed. It can't be up to the reader to guess what e.g. >>>>> "invokeMessageHandler" does, right?? (section 8.7). In this=20 >>>>> particular section, I would also expect the text and/or pseudocode=20 >>>>> to somehow draw a relationship to "push" (listed in fig. 3), but=20 >>>>> that's not there... so what is this? >>>>=20 >>>> We agree that this pseudocode is more general and applies to both=20 >>>> algorithms. To avoid duplication, we have moved it from Section 8=20 >>>> to the relevant subsections in Section 7. >>>=20 >>> Fine. >>>=20 >>>>> 4) Structure: even if the two algorithms are only a part of the=20 >>>>> whole thing you define, the text going with them feels a bit like=20 >>>>> "we've set the stage, now we apply it - the messages you heard=20 >>>>> about before are used like this & that with this & that=20 >>>>> algorithm". That's fine! But it also gives the reader the feeling=20 >>>>> 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=20 >>>> sections, but we don't agree that moving it to the end will help=20 >>>> the understanding of the draft. >>>=20 >>> Fine. >>>=20 >>>>> 5) I also think that it would be better to move the examples=20 >>>>> (section 12) to where you introduce the messages, the flow of=20 >>>>> which they illustrate. First I have to imagine what an "INVITE"=20 >>>>> message flow could look like, then I get complicated explanations=20 >>>>> of how INVITE is applied in an algorithm that I can't fully=20 >>>>> understand from this text anyway, and THEN I get a nice example=20 >>>>> illustrating an INVITE message flow... that's not very helpful for=20 >>>>> the reader I think. e.g., when I read 7.2.3, I wondered why the=20 >>>>> "peer_id" of the source peer is even needed in the struct. By=20 >>>>> 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=20 >>>> not first. The examples follow the definition of the messages=20 >>>> sothat the message use is illustrated. If we moved the examples=20 >>>> first, then some other reviewer could then say . why are the=20 >>>> examplesshown before the protocol messages are defined? It is not=20 >>>> the purpose of the ID to bootstrap the reader into basic knowledge=20 >>>> of ALM and Peer to Peer messaging. >>>>=20 >>> Fine. >>>=20 >>>>> 6) Speaking of the examples, what's the point of showing more=20 >>>>> peers than you actually use in the example? Okay, I can understand=20 >>>>> that perhaps you wanted to have the same number for all of them,=20 >>>>> but then you could still remove P3 because it seems that you never=20 >>>>> use P3 for anything in any of the examples. >>>>=20 >>>> We added these peers is to illustrate that 1) not all the peers in=20 >>>> the overlay have to be part of each ALM connection, and 2) the=20 >>>> overlay could have an arbitrary number of peers. >>>=20 >>> Well, even a total P2P nut like myself understands that without even=20 >>> 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) >>>>> - btw, why is the section called "Algorithm Codes" but then the=20 >>>>> text talks about "Algorithm Types" ? >>>>>=20 >>>> There are no IANA considerations since this is to be an=20 >>>> informational RFC. >>>=20 >>> Ah, ok, sure - >>>=20 >>>>> 8) Some references (CASTRO2003, P2PCAST) need a space (I mean, "=20 >>>>> ") after their first appearance. >>>>> cut..... >>>>>=20 >>>> All these edits have been done and version 03 has been submitted. >>>=20 >>> Fine, thanks! >>>=20 >>> Cheers, >>> Michael >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> SAM mailing list >> SAM@irtf.org >> http://www.irtf.org/mailman/listinfo/sam >>=20 >=20 > -- >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-84= 09 =B0 _______________________________________________ SAM mailing list SAM@irtf.org http://www.irtf.org/mailman/listinfo/sam From michawe@ifi.uio.no Wed May 1 07:58:19 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 0B78121F991A; Wed, 1 May 2013 07:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, 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 jDodAVw6jZKi; Wed, 1 May 2013 07:58:14 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 34F8221F98B3; Wed, 1 May 2013 07:58:13 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UXYTz-0002mI-1f; Wed, 01 May 2013 16:58:11 +0200 Received: from 213.246.16.62.customer.cdi.no ([62.16.246.213] helo=[192.168.0.103]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1UXYTx-0001u5-QZ; Wed, 01 May 2013 16:58:11 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Michael Welzl In-Reply-To: <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com> Date: Wed, 1 May 2013 16:58:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1599A8CE-8979-426D-A208-44D8C6288687@ifi.uio.no> References: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> <4B1FBAB9-36C6-42B5-B976-6A156C72E432@ifi.uio.no> <517CD713.3060006@informatik.haw-hamburg.de> <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no> <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com> To: "Buford, John F (John)" X-Mailer: Apple Mail (2.1503) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 9 sum msgs/h 4 total rcpts 4052 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3EB6FD00B1E06DE56E19B3C359CC5760BA09D387 X-UiO-SPAM-Test: remote_host: 62.16.246.213 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 498 max/h 8 blacklist 0 greylist 0 ratelimit 0 Cc: "sam@irtf.org" , Internet Research Steering Group 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, 01 May 2013 14:58:19 -0000 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)" = wrote: > Michael, >=20 > Thanks for your review. >=20 > We didn't have it as experimental since it doesn't report on an = implementation. >=20 > John >=20 > -----Original Message----- > From: sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] On Behalf Of = Michael Welzl > Sent: Wednesday, May 01, 2013 5:38 AM > To: Thomas C. Schmidt; Internet Research Steering Group; sam@irtf.org > Subject: Re: [SAM] [irsg] IRSG review for = draft-irtf-samrg-sam-baseline-protocol-02 >=20 > Hi, >=20 > Yes. >=20 > One (non-blocking) question: why is this intended as Informational, = and not Experimental? The latter would seem more appropriate to me. >=20 > Cheers, > Michael >=20 >=20 > On Apr 28, 2013, at 10:00 AM, Thomas C. Schmidt = wrote: >=20 >> Hi Michael, >>=20 >> this means a "ready to publish" vote? >>=20 >> Viele Gr=FC=DFe >>=20 >> Thomas >>=20 >> On 28.04.2013 07:23, Michael Welzl wrote: >>> Hi, >>>=20 >>> I just noticed that somehow, irsg and samrg were dropped from the=20 >>> list of recipients of this response, sorry >>>=20 >>> Begin forwarded message: >>>=20 >>>> *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 >>>> > >>>>=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 >>>>>> General higher-level comments: >>>>>>=20 >>>>>> 1) I found parts of the document very hard to read, sometimes=20 >>>>>> wondered if this is really necessary. >>>>>>=20 >>>>> The document is intended for an audience which does have a=20 >>>>> technical background in the area of application layer multicasting=20= >>>>> and peer to peer overlay protocols. We would expect readers=20 >>>>> unfamiliar with the area to first go to more basic material.=20 >>>>> Perhaps many comments in the review stem from the fact that the=20 >>>>> reviewer doesn't have this familiarity. To help readers to get a=20= >>>>> better understanding we have added references to introductory and=20= >>>>> background material as a starting point: >>>>>=20 >>>>> J. Buford, H. Yu, E. K. Lua P2P Networking and Applications. = Morgan=20 >>>>> Kaufman 2009 (Ch 9 Peercasting and Overlay Multicasting). >>>>> M. Kolberg. Employing Multicast in P2P Networks, in: Handbook of=20= >>>>> Peer-to-Peer Networking. (Ed. X. Shen, H. Yu, J. Buford, M. Akon). >>>>> J. Buford and H. Yu. Peer-to-Peer Overlay Multicast, in:=20 >>>>> Encyclopedia of Wireless and Mobile Communications. 2008. >>>>>=20 >>>> Good! >>>> I would like to mention that, while I know very little about=20 >>>> 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=20 >>>> and also taught a lecture about it a few years ago (which even=20 >>>> contained a brief overview of Scribe, IIRC). So that made me think,=20= >>>> someone like me should at least be able to make some sense of the=20= >>>> document - within certain limits of course, as I know nothing about=20= >>>> RELOAD, for example. >>>>=20 >>>>=20 >>>>>> 2) In particular, P2PCast appears to be a rather complex = algorithm=20 >>>>>> which is "sort of" described here... I doubt that the description=20= >>>>>> in the document will help most readers to really fully understand=20= >>>>>> P2PCast, and I wonder, is it necessary for this doc to try to=20 >>>>>> really explain the algorithm (when, in doing so, it can really=20 >>>>>> only go half-way anyway)? e.g., wouldn't it suffice to just keep=20= >>>>>> the "Overview" (section 9.1) but then point to [P2PCAST] for=20 >>>>>> further details, and just list the necessary facts? e.g., the = JOIN=20 >>>>>> 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=20 >>>>>> in accordance with [P2PCAST]? >>>>> The ID is written for a technical audience which is presumed to be=20= >>>>> knowledgeable about RELOAD and P2P overlays and has = somefamiliarity=20 >>>>> with multicasting at the application layer. We provide summaries = of=20 >>>>> P2PCAST and SCRIBE since these two algorithms are well known in = the=20 >>>>> ALM research community, and are each representative of an = important=20 >>>>> class of ALM algorithms. If the reader needs more background, = then=20 >>>>> they can go to thereference papers and find it there. >>>>>=20 >>>>> In our opinion, the inclusion of the essential features about each=20= >>>>> algorithm is useful and should be in the ID. The level of=20 >>>>> detaildescribes "Scribe-like" and "P2PCast-like" algorithms, and=20= >>>>> not only Scribe and P2PCAST. Since the protocol we define is=20 >>>>> 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=20 >>>>> information about the Chord algorithm, but yet omits Chord details=20= >>>>> which one would find in the original papers from MIT. If your=20 >>>>> 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=20= >>>>> important previously existing algorithms are summarized in an ID. >>>>=20 >>>> Well. I'm not sure if the cases you compare here really are=20 >>>> 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,=20 >>>> I think - its overall intention is different from a document like=20= >>>> this one. But I see your point about trying to convey the essential=20= >>>> features right here, and if you feel the text explains the = essential=20 >>>> bits and is helpful, I'll trust you on this one, given my lack of=20= >>>> expertise in application-layer multicast. >>>>=20 >>>>=20 >>>>>> 3) Another source of confusion: the Scribe algorithm description=20= >>>>>> has some pseudocode that I wasn't able to parse (maybe it refers=20= >>>>>> to RELOAD things?) Not all functions there seem to clearly relate=20= >>>>>> to messages that were described earlier. Even more confusing, the=20= >>>>>> P2PCast algorithm description doesn't have these pseudocode=20 >>>>>> snippets, so the whole thing appears inconsistent. Should it be=20= >>>>>> everywhere? Should it be removed? If it stays, some explanations=20= >>>>>> are needed. It can't be up to the reader to guess what e.g. >>>>>> "invokeMessageHandler" does, right?? (section 8.7). In this=20 >>>>>> particular section, I would also expect the text and/or = pseudocode=20 >>>>>> to somehow draw a relationship to "push" (listed in fig. 3), but=20= >>>>>> that's not there... so what is this? >>>>>=20 >>>>> We agree that this pseudocode is more general and applies to both=20= >>>>> algorithms. To avoid duplication, we have moved it from Section 8=20= >>>>> to the relevant subsections in Section 7. >>>>=20 >>>> Fine. >>>>=20 >>>>>> 4) Structure: even if the two algorithms are only a part of the=20= >>>>>> whole thing you define, the text going with them feels a bit like=20= >>>>>> "we've set the stage, now we apply it - the messages you heard=20 >>>>>> about before are used like this & that with this & that=20 >>>>>> algorithm". That's fine! But it also gives the reader the feeling=20= >>>>>> 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=20= >>>>> sections, but we don't agree that moving it to the end will help=20= >>>>> the understanding of the draft. >>>>=20 >>>> Fine. >>>>=20 >>>>>> 5) I also think that it would be better to move the examples=20 >>>>>> (section 12) to where you introduce the messages, the flow of=20 >>>>>> which they illustrate. First I have to imagine what an "INVITE"=20= >>>>>> message flow could look like, then I get complicated explanations=20= >>>>>> of how INVITE is applied in an algorithm that I can't fully=20 >>>>>> understand from this text anyway, and THEN I get a nice example=20= >>>>>> illustrating an INVITE message flow... that's not very helpful = for=20 >>>>>> the reader I think. e.g., when I read 7.2.3, I wondered why the=20= >>>>>> "peer_id" of the source peer is even needed in the struct. By=20 >>>>>> 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=20= >>>>> not first. The examples follow the definition of the messages=20 >>>>> sothat the message use is illustrated. If we moved the examples=20= >>>>> first, then some other reviewer could then say . why are the=20 >>>>> examplesshown before the protocol messages are defined? It is not=20= >>>>> the purpose of the ID to bootstrap the reader into basic knowledge=20= >>>>> of ALM and Peer to Peer messaging. >>>>>=20 >>>> Fine. >>>>=20 >>>>>> 6) Speaking of the examples, what's the point of showing more=20 >>>>>> peers than you actually use in the example? Okay, I can = understand=20 >>>>>> that perhaps you wanted to have the same number for all of them,=20= >>>>>> but then you could still remove P3 because it seems that you = never=20 >>>>>> use P3 for anything in any of the examples. >>>>>=20 >>>>> We added these peers is to illustrate that 1) not all the peers in=20= >>>>> the overlay have to be part of each ALM connection, and 2) the=20 >>>>> overlay could have an arbitrary number of peers. >>>>=20 >>>> Well, even a total P2P nut like myself understands that without = even=20 >>>> 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) >>>>>> - btw, why is the section called "Algorithm Codes" but then the=20= >>>>>> text talks about "Algorithm Types" ? >>>>>>=20 >>>>> There are no IANA considerations since this is to be an=20 >>>>> informational RFC. >>>>=20 >>>> Ah, ok, sure - >>>>=20 >>>>>> 8) Some references (CASTRO2003, P2PCAST) need a space (I mean, "=20= >>>>>> ") after their first appearance. >>>>>> cut..... >>>>>>=20 >>>>> All these edits have been done and version 03 has been submitted. >>>>=20 >>>> Fine, thanks! >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> SAM mailing list >>> SAM@irtf.org >>> http://www.irtf.org/mailman/listinfo/sam >>>=20 >>=20 >> -- >>=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 >=20 > _______________________________________________ > SAM mailing list > SAM@irtf.org > http://www.irtf.org/mailman/listinfo/sam From lars@netapp.com Wed May 1 08:28:34 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 7ACEE21F97F6; Wed, 1 May 2013 08:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.827 X-Spam-Level: X-Spam-Status: No, score=-9.827 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 7c1dhwh2HPSw; Wed, 1 May 2013 08:28:30 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 60D5A21F97EE; Wed, 1 May 2013 08:28:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,589,1363158000"; d="scan'208";a="46917118" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 01 May 2013 08:28:07 -0700 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r41FS7Mi013861; Wed, 1 May 2013 08:28:07 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 1 May 2013 08:28:07 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.71]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Wed, 1 May 2013 08:28:07 -0700 From: "Eggert, Lars" To: Michael Welzl Thread-Topic: [SAM] [irsg] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02 Thread-Index: AQHORnxVupqGxZCllE+P+jfJIdCKv5jw6VIA Date: Wed, 1 May 2013 15:28:06 +0000 Message-ID: <1896D978-7B37-4902-8C63-0B60716C3F2E@netapp.com> References: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> <4B1FBAB9-36C6-42B5-B976-6A156C72E432@ifi.uio.no> <517CD713.3060006@informatik.haw-hamburg.de> <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no> <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com> <1599A8CE-8979-426D-A208-44D8C6288687@ifi.uio.no> In-Reply-To: <1599A8CE-8979-426D-A208-44D8C6288687@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4105232C55A3B0499ACD8B382907B1F5@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sam@irtf.org" , Internet Research Steering Group 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, 01 May 2013 15:28:34 -0000 On May 1, 2013, at 16:58, Michael Welzl wrote: > Not sure that's needed?! > http://www.ietf.org/iesg/informational-vs-experimental.html doesn't say a= nything about requiring an implementation, unless I missed it It's not needed. Pick whatever seems most appropriate. (The IETF rules at the URL above are a good guideline, but don't actually a= pply to the I*R*TF.) Lars= From buford@samrg.org Wed May 1 08:55:53 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 87EF121F9A6B for ; Wed, 1 May 2013 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.07 X-Spam-Level: X-Spam-Status: No, score=-100.07 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 31zlAXaRhVEo for ; Wed, 1 May 2013 08:55:48 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id BF54921F9A69 for ; Wed, 1 May 2013 08:55:48 -0700 (PDT) Received: (qmail 1037 invoked by uid 0); 1 May 2013 15:55:21 -0000 Received: from unknown (HELO host181.hostmonster.com) (74.220.207.181) by oproxy7.bluehost.com with SMTP; 1 May 2013 15:55:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samrg.org; s=default; h=To:Date:Subject:From:Cc:Message-Id:Content-Transfer-Encoding:Content-Type:In-Reply-To:Mime-Version:References; bh=qc8vW28tttzNGcB6S9YO/p0WZz7ZZf4cIAE6tGv9Eec=; b=AeFAnXlVjUwzLD1ICb9S6bBXS13CMK45KOSlrQb/Odc2pZBnn7tjuGEudZs7yjDGTPV3IIaT+jnmcooVGhBtNP3Rb2ZKb9pa8ao/1KoI7OIBAgfq193G+T/0SwSdQN0c; Received: from [198.228.206.87] (port=54435 helo=[10.16.115.220]) by host181.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UXZNJ-0001iF-4d; Wed, 01 May 2013 09:55:21 -0600 References: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> <4B1FBAB9-36C6-42B5-B976-6A156C72E432@ifi.uio.no> <517CD713.3060006@informatik.haw-hamburg.de> <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no> <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com> <1599A8CE-8979-426D-A208-44D8C6288687@ifi.uio.no> <1896D978-7B37-4902-8C63-0B60716C3F2E@netapp.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1896D978-7B37-4902-8C63-0B60716C3F2E@netapp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <473DFE40-C402-4A75-87CF-2157F005CCDD@samrg.org> X-Mailer: iPad Mail (10B329) From: John Buford Date: Wed, 1 May 2013 11:58:53 -0400 To: "Eggert, Lars" X-Identified-User: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth 198.228.206.87 authed with buford@samrg.org} Cc: "sam@irtf.org" , Michael Welzl , Internet Research Steering Group 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, 01 May 2013 15:55:53 -0000 Thanks for the pointer. It does seem then that experimental would be more a= ccurate. Can we change that after the formal poll ends or should we change it now? John Sent from my iPad On May 1, 2013, at 11:28 AM, "Eggert, Lars" wrote: > On May 1, 2013, at 16:58, Michael Welzl wrote: >> Not sure that's needed?! >> http://www.ietf.org/iesg/informational-vs-experimental.html doesn't say a= nything about requiring an implementation, unless I missed it >=20 > It's not needed. Pick whatever seems most appropriate. >=20 > (The IETF rules at the URL above are a good guideline, but don't actually a= pply to the I*R*TF.) >=20 > Lars From lars@netapp.com Wed May 1 10:31:39 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 B5D6E21F8FEC; Wed, 1 May 2013 10:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 LfVO3CCcu3G4; Wed, 1 May 2013 10:31:34 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C0D5A21F9ABC; Wed, 1 May 2013 10:31:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,590,1363158000"; d="scan'208";a="46971292" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 01 May 2013 10:31:31 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r41HVUP3017198; Wed, 1 May 2013 10:31:30 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 1 May 2013 10:31:30 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.71]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.02.0342.003; Wed, 1 May 2013 10:31:29 -0700 From: "Eggert, Lars" To: John Buford Thread-Topic: [irsg] [SAM] IRSG review for draft-irtf-samrg-sam-baseline-protocol-02 Thread-Index: AQHORoRcUqavUo9ck0qVRRTlwGBeA5jxC7wA Date: Wed, 1 May 2013 17:31:29 +0000 Message-ID: References: <0A9F560A-846B-40DC-83BB-DE85D7486606@ifi.uio.no> <4B1FBAB9-36C6-42B5-B976-6A156C72E432@ifi.uio.no> <517CD713.3060006@informatik.haw-hamburg.de> <0297C4A1-18B3-4485-AEF2-9D29667C3E5B@ifi.uio.no> <48E0C724888CBE47A7912FCEB14DF8F406F0E2@AZ-US1EXMB02.global.avaya.com> <1599A8CE-8979-426D-A208-44D8C6288687@ifi.uio.no> <1896D978-7B37-4902-8C63-0B60716C3F2E@netapp.com> <473DFE40-C402-4A75-87CF-2157F005CCDD@samrg.org> In-Reply-To: <473DFE40-C402-4A75-87CF-2157F005CCDD@samrg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <06E7DC71D5D59F4B85F7AF84503D3E60@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sam@irtf.org" , Michael Welzl , Internet Research Steering Group 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, 01 May 2013 17:31:40 -0000 On May 1, 2013, at 17:58, John Buford wrote: > Thanks for the pointer. It does seem then that experimental would be mo= re accurate. > Can we change that after the formal poll ends or should we change it now? After is fine. The IRSG is CC'ed, so they can take the change to Experiment= al into account when reviewing.=20 Thanks, Lars= From lars@netapp.com Mon May 6 02:06: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 B1DEF21F8F6D; Mon, 6 May 2013 02:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.8 X-Spam-Level: X-Spam-Status: No, score=-9.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HiHIX1cDUyeO; Mon, 6 May 2013 02:06:17 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC8321F8F50; Mon, 6 May 2013 02:06:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,620,1363158000"; d="scan'208";a="49863028" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 06 May 2013 02:06:17 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r4696GoY023878; Mon, 6 May 2013 02:06:17 -0700 (PDT) Received: from VMWEXCEHT06-PRD.hq.netapp.com (10.106.77.104) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 6 May 2013 02:06:17 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.71]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Mon, 6 May 2013 02:06:16 -0700 From: "Eggert, Lars" To: IESG IESG Thread-Topic: Request for RFC5742 review of draft-irtf-samrg-common-api-08 Thread-Index: AQHOSjj2sRoO/sg5xE2AELYVNjPTtQ== Date: Mon, 6 May 2013 09:06:15 +0000 Message-ID: <6F526BB1-B5F3-4797-A472-C474E33DCAC9@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="utf-8" Content-ID: <7D9384E827823D428C3EBE9DD20059E3@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sam@irtf.org" , Internet Research Steering Group Subject: [SAM] Request for RFC5742 review of 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: Mon, 06 May 2013 09:06:21 -0000 SGksIElFU0cgc2VjcmV0YXJ5IChCQ0MnZWQpLA0KDQp0aGlzIGlzIGEgcmVxdWVzdCBmb3IgdGhl IElFU0cgdG8gcGVyZm9ybSBhbiBSRkM1NzQyIHJldmlldyBvZiBkcmFmdC1pcnRmLXNhbXJnLWNv bW1vbi1hcGktMDggZnJvbSB0aGUgU0FNUkcsIHRvIGJlIHB1Ymxpc2hlZCBhcyBhbiBFeHBlcmlt ZW50YWwgUkZDIG9uIHRoZSBJUlRGIFN0cmVhbS4NCg0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiBh cHByb3ZlZCBmb3IgcHVibGljYXRpb24gYnkgdGhlIElSU0cuIFNlZSBodHRwOi8vd2lraS50b29s cy5pZXRmLm9yZy9ncm91cC9pcnRmL3RyYWMvdGlja2V0LzUwIGZvciBkZXRhaWxzIG9uIHByaW9y IHJldmlld3MuIFBsZWFzZSBjb3B5IGFsbCBjb3JyZXNwb25kZW5jZSB0byB0aGUgZG9jdW1lbnQg c2hlcGhlcmQsIEpvaG4gQnVmb3JkICjigItidWZvcmRAc2Ftcmcub3JnKS4NCg0KVGhhbmtzLA0K TGFycw0KDQo=