From mko@cs.stir.ac.uk Thu Jun 6 08:29: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 D3E0021F997A for ; Thu, 6 Jun 2013 08:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Mnj36537Eg3y for ; Thu, 6 Jun 2013 08:29:28 -0700 (PDT) Received: from clyde.stir.ac.uk (clyde.stir.ac.uk [139.153.13.35]) by ietfa.amsl.com (Postfix) with ESMTP id 61E6821F99B6 for ; Thu, 6 Jun 2013 08:29:28 -0700 (PDT) Received: from smtp1.stir.ac.uk ([139.153.12.131]) by clyde.stir.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ukc7r-000688-Gz for sam@irtf.org; Thu, 06 Jun 2013 16:29:19 +0100 Received: from d253004.cs.stir.ac.uk ([139.153.253.4]) by smtp1.stir.ac.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ukc7r-0004s8-BQ for sam@irtf.org; Thu, 06 Jun 2013 16:29:19 +0100 Message-ID: <51B0AAD1.7070202@cs.stir.ac.uk> Date: Thu, 06 Jun 2013 16:29:21 +0100 From: Dr Mario Kolberg User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sam References: <51B0AA7B.2020500@cs.stir.ac.uk> In-Reply-To: <51B0AA7B.2020500@cs.stir.ac.uk> X-Forwarded-Message-Id: <51B0AA7B.2020500@cs.stir.ac.uk> Content-Type: multipart/alternative; boundary="------------090902080607090605060002" X-stir.ac.uk-MailScanner-ID: 1Ukc7r-000688-Gz X-stir.ac.uk-MailScanner: Found to be clean Subject: [SAM] Fwd: Re: [irsg] IRSG Poll 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: Thu, 06 Jun 2013 15:29:34 -0000 This is a multi-part message in MIME format. --------------090902080607090605060002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sorry forgot to copy to the SAM list. Thanks, Mario -------- Original Message -------- Subject: Re: [irsg] IRSG Poll for draft-irtf-samrg-sam-baseline-protocol-02 Date: Thu, 06 Jun 2013 16:27:55 +0100 From: Dr Mario Kolberg To: Joerg Ott CC: Eggert, Lars , Internet Research Steering Group , John Buford , Thomas C. Schmidt , Michael Welzl Dear Joerg, many thanks for your comments on the SAM baseline draft. We have taken your comments into account and have made changes to the document as detailed below (inline with your comments). We have also changed the document status to Experimental (as per earlier comment by Michael Welzl). An updated version 04 has been submitted. Many thanks, Mario and John On 23/05/2013 19:48, Joerg Ott wrote: > Hi, > > basically, this is almost ready to publish. Just a couple of points on > this draft that should be easy to fix: > > Section 1: > > o trees connect nodes over the global Internet > > This does not fit with the sentence structure of the remaining list > items. > fixed. > Section 5: > > o Register Kind-Id points > > Code points? > > Again, the enumeration list is inconsistent with the intro line > before. And the verbs are inconsistent across the lines. The > first sentence after the list should be capitalized. > fixed. > Section 6: > > 1st para after the bullet list: should probably not use "We". > > Improve readability of the comments in the pseudo code. > Be consistent in whether descriptions should be presented as > text or comments. (fix item 1.) > > Item 5. is probably just explanation text for item 4. > fixed. > Section 7.2.3: > > Suggestions for clarifications: > > CHANGE: > JoinConfirm -- JoinConfirmResponse: If node P sent node C a > JoinAccept, then node C confirms with a JoinConfirm request. Node > P then responds with a JoinConfirmResponse. > -> > JoinConfirm -- JoinConfirmResponse: If node P sent node C a > JoinAccept and node C confirms with a JoinConfirm request then > Node P then responds with a JoinConfirmResponse. > > CHANGE: > JoinDecline -- JoinDeclineResponse: If node P sent node C a > JoinAccept, then node C declines with a JoinDecline request. Node > P then responds with a JoinDeclineResponse > -> > JoinDecline -- JoinDeclineResponse: If node P sent node C a > JoinAccept and node C declines with a JoinDecline request then > Node P then responds with a JoinDeclineResponse > fixed. > Section 7.2.4: > > This section defines that a JoinAccept times out when it does not > receive a JoinDecline or JoinConfirm. There is a default timeout > in ImplementationInfo but this messages does not seem to be > distributed as mandatory. So, how does a newly joining node > learn this value? Or would it always assume the default? > In any case, a short hint might be useful here. (The information > is probably carried in the options either of the JoinAccept or > an earlier Fetch, so maybe make this explicit?) > Added a statement to this section. > Section 7.2.14: > > Same here: make explicit where the heartbeat interval comes from. > Added a statement to this section. > Section 7.2.16: > > Since the semantics appear fixed, should one name nodes 1 and 2 > as src and dst? > done. > Section 7.2.17: > > For the heartbeat interval, in contrast to the join_timeout, > it is not specified that nodes can change this value. If they > cannot change the value, why communicate it? And what should > a node assume if it receives a value different from the > predefined one? Fail? Report an error? Use it? > > Generally, it appears that the communication and use of parameters > could be a bit more elaborate. > > Section 9.2: > > "as defined in Section 5 of this draft" > > s/draft/document/ > done. > Sections 8 and 9, albeit defining protocol mappings, do not use the > normative language. Just checking that this is intentional. > Given that section 11.4 registers these uses, I'd be leaning more > towards a normative language. > we now use normative language in these sections. > Section 10: > > Just curious: > > Wouldn't an IANA-registered code point make more sense for an RFC? > (but you have probably been through this before) > > Potential implications on IANA considerations. > > Section 11: > > The same can be argued for the message type. > Section 15 has been extended and now contains the ALM algorithm types, as well as the message code and error code registrations. > MUST not -> MUST NOT > fixed. On 24/05/2013 09:35, Joerg Ott wrote: > Hi Lars, > >> thanks for the detailed review, Jörg. I read this as "ready to >> publish, once these changes are made"? > > yes. > > Jörg > >> If so, authors, please update ASAP, so we can get this out before the >> RG closes. >> >> Thanks, >> Lars >> -- 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. --------------090902080607090605060002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sorry forgot to copy to the SAM list.

Thanks,
Mario

-------- Original Message --------
Subject: Re: [irsg] IRSG Poll for draft-irtf-samrg-sam-baseline-protocol-02
Date: Thu, 06 Jun 2013 16:27:55 +0100
From: Dr Mario Kolberg <mko@cs.stir.ac.uk>
To: Joerg Ott <jo@netlab.tkk.fi>
CC: Eggert, Lars <lars@netapp.com>, Internet Research Steering Group <irsg@irtf.org>, John Buford <buford@samrg.org>, Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de>, Michael Welzl <michawe@ifi.uio.no> 


Dear Joerg,

many thanks for your comments on the SAM baseline draft. We have taken 
your comments into account and have made changes to the document as 
detailed below (inline with your comments). We have also changed the 
document status to Experimental (as per earlier comment by Michael 
Welzl). An updated version 04 has been submitted.

Many thanks,
Mario and John

On 23/05/2013 19:48, Joerg Ott wrote:
> Hi,
>
> basically, this is almost ready to publish.  Just a couple of points on
> this draft that should be easy to fix:
>
> Section 1:
>
>    o  trees connect nodes over the global Internet
>
>    This does not fit with the sentence structure of the remaining list
>    items.
>
fixed.
> Section 5:
>
>    o  Register Kind-Id points
>
>    Code points?
>
>    Again, the enumeration list is inconsistent with the intro line
>    before.  And the verbs are inconsistent across the lines. The
>    first sentence after the list should be capitalized.
>
fixed.
> Section 6:
>
>    1st para after the bullet list: should probably not use "We".
>
>    Improve readability of the comments in the pseudo code.
>    Be consistent in whether descriptions should be presented as
>    text or comments.  (fix item 1.)
>
>    Item 5. is probably just explanation text for item 4.
>
fixed.
> Section 7.2.3:
>
>    Suggestions for clarifications:
>
>    CHANGE:
>       JoinConfirm -- JoinConfirmResponse: If node P sent node C a
>       JoinAccept, then node C confirms with a JoinConfirm request.  Node
>       P then responds with a JoinConfirmResponse.
>   ->
>       JoinConfirm -- JoinConfirmResponse: If node P sent node C a
>       JoinAccept and node C confirms with a JoinConfirm request then
>       Node P then responds with a JoinConfirmResponse.
>
>   CHANGE:
>       JoinDecline -- JoinDeclineResponse: If node P sent node C a
>       JoinAccept, then node C declines with a JoinDecline request.  Node
>       P then responds with a JoinDeclineResponse
>   ->
>       JoinDecline -- JoinDeclineResponse: If node P sent node C a
>       JoinAccept and node C declines with a JoinDecline request then
>       Node P then responds with a JoinDeclineResponse
>
fixed.
> Section 7.2.4:
>
>    This section defines that a JoinAccept times out when it does not
>    receive a JoinDecline or JoinConfirm.  There is a default timeout
>    in ImplementationInfo but this messages does not seem to be
>    distributed as mandatory.  So, how does a newly joining node
>    learn this value?  Or would it always assume the default?
>    In any case, a short hint might be useful here.  (The information
>    is probably carried in the options either of the JoinAccept or
>    an earlier Fetch, so maybe make this explicit?)
>
Added a statement to this section.
> Section 7.2.14:
>
>    Same here: make explicit where the heartbeat interval comes from.
>
Added a statement to this section.
> Section 7.2.16:
>
>    Since the semantics appear fixed, should one name nodes 1 and 2
>    as src and dst?
>
done.
> Section 7.2.17:
>
>    For the heartbeat interval, in contrast to the join_timeout,
>    it is not specified that nodes can change this value.  If they
>    cannot change the value, why communicate it?  And what should
>    a node assume if it receives a value different from the
>    predefined one?  Fail?  Report an error?  Use it?
>
> Generally, it appears that the communication and use of parameters
> could be a bit more elaborate.
>
> Section 9.2:
>
>    "as defined in Section 5 of this draft"
>
>    s/draft/document/
>
done.
> Sections 8 and 9, albeit defining protocol mappings, do not use the
> normative language.  Just checking that this is intentional.
> Given that section 11.4 registers these uses, I'd be leaning more
> towards a normative language.
>
we now use normative language in these sections.

> Section 10:
>
>    Just curious:
>
>    Wouldn't an IANA-registered code point make more sense for an RFC?
>    (but you have probably been through this before)
>
>    Potential implications on IANA considerations.
>
> Section 11:
>
>    The same can be argued for the message type.
>
Section 15 has been extended and now contains the ALM algorithm types, 
as well as the message code and error code registrations.
> MUST not -> MUST NOT
>
fixed.

On 24/05/2013 09:35, Joerg Ott wrote:
> Hi Lars,
>
>> thanks for the detailed review, Jörg. I read this as "ready to 
>> publish, once these changes are made"?
>
> yes.
>
> Jörg
>
>> If so, authors, please update ASAP, so we can get this out before the 
>> RG closes.
>>
>> Thanks,
>> Lars
>>
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.
--------------090902080607090605060002-- From buford@samrg.org Tue Jun 11 12:13:20 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 8AD6121F8F9E for ; Tue, 11 Jun 2013 12:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 VdEVDh8NAW9V for ; Tue, 11 Jun 2013 12:13:15 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id E628321F8607 for ; Tue, 11 Jun 2013 12:13:14 -0700 (PDT) Received: (qmail 8917 invoked by uid 0); 11 Jun 2013 19:12:53 -0000 Received: from unknown (HELO host181.hostmonster.com) (74.220.207.181) by oproxy13.unifiedlayer.com with SMTP; 11 Jun 2013 19:12:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samrg.org; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=7beAlaKzxsUGyPks+kHxbik4GMeuTHBunQB1b4Bb4m8=; b=b/N6t9jl2yZmdHoFWgfMvV6TsnsIGIqVwZdwD1TFafJTC2yz1OwEeoE+OcMDyxCEPfiX4WH6k/s2s2q/4f/QVOFr8bTwy1jxHX0ZD2VPiDYNYwpaAVgAfnQM68vesv1X; Received: from [68.38.211.16] (port=55621 helo=Avalon) by host181.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UmTzw-0002Sv-P2 for sam@irtf.org; Tue, 11 Jun 2013 13:12:52 -0600 From: "John Buford" To: "'sam'" References: <517BD1B0.2060007@informatik.haw-hamburg.de> <8198246B-207B-4E98-B32B-FF57DD535270@netapp.com> <7055BE7F-C733-434B-841C-EB21A15700EA@netapp.com> <519E646D.5000608@netlab.tkk.fi> <120C2C91-FC1C-4C3D-92F5-AAB1C7590FEE@netapp.com> <519F264F.2060005@netlab.tkk.fi> In-Reply-To: <519F264F.2060005@netlab.tkk.fi> Date: Tue, 11 Jun 2013 15:12:49 -0400 Message-ID: <0a9401ce66d7$aabfa050$003ee0f0$@samrg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGxCZyUKHndlpuT2lDY5yhpkzsWRQJ9T4PbAaxdda8Cr5L1aAHzIPiOAlzvAeaZElGDUA== X-Identified-User: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth 68.38.211.16 authed with buford@samrg.org} Subject: [SAM] FW: [irsg] IRSG Poll 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: Tue, 11 Jun 2013 19:13:20 -0000 -----Original Message----- From: Joerg Ott [mailto:jo@netlab.tkk.fi]=20 Sent: Friday, May 24, 2013 4:35 AM To: Eggert, Lars Cc: Internet Research Steering Group; John Buford; ; Thomas C. Schmidt Subject: Re: [irsg] IRSG Poll for = draft-irtf-samrg-sam-baseline-protocol-02 Hi Lars, > thanks for the detailed review, J=F6rg. I read this as "ready to = publish, once these changes are made"? yes. J=F6rg > If so, authors, please update ASAP, so we can get this out before the = RG closes. > > Thanks, > Lars > > On May 23, 2013, at 20:48, Joerg Ott wrote: > >> Hi, >> >> basically, this is almost ready to publish. Just a couple of points=20 >> on this draft that should be easy to fix: >> >> Section 1: >> >> o trees connect nodes over the global Internet >> >> This does not fit with the sentence structure of the remaining = list >> items. >> >> Section 5: >> >> o Register Kind-Id points >> >> Code points? >> >> Again, the enumeration list is inconsistent with the intro line >> before. And the verbs are inconsistent across the lines. The >> first sentence after the list should be capitalized. >> >> Section 6: >> >> 1st para after the bullet list: should probably not use "We". >> >> Improve readability of the comments in the pseudo code. >> Be consistent in whether descriptions should be presented as >> text or comments. (fix item 1.) >> >> Item 5. is probably just explanation text for item 4. >> >> Section 7.2.3: >> >> Suggestions for clarifications: >> >> CHANGE: >> JoinConfirm -- JoinConfirmResponse: If node P sent node C a >> JoinAccept, then node C confirms with a JoinConfirm request. = Node >> P then responds with a JoinConfirmResponse. >> -> >> JoinConfirm -- JoinConfirmResponse: If node P sent node C a >> JoinAccept and node C confirms with a JoinConfirm request then >> Node P then responds with a JoinConfirmResponse. >> >> CHANGE: >> JoinDecline -- JoinDeclineResponse: If node P sent node C a >> JoinAccept, then node C declines with a JoinDecline request. = Node >> P then responds with a JoinDeclineResponse >> -> >> JoinDecline -- JoinDeclineResponse: If node P sent node C a >> JoinAccept and node C declines with a JoinDecline request then >> Node P then responds with a JoinDeclineResponse >> >> >> Section 7.2.4: >> >> This section defines that a JoinAccept times out when it does not >> receive a JoinDecline or JoinConfirm. There is a default timeout >> in ImplementationInfo but this messages does not seem to be >> distributed as mandatory. So, how does a newly joining node >> learn this value? Or would it always assume the default? >> In any case, a short hint might be useful here. (The information >> is probably carried in the options either of the JoinAccept or >> an earlier Fetch, so maybe make this explicit?) >> >> Section 7.2.14: >> >> Same here: make explicit where the heartbeat interval comes from. >> >> Section 7.2.16: >> >> Since the semantics appear fixed, should one name nodes 1 and 2 >> as src and dst? >> >> Section 7.2.17: >> >> For the heartbeat interval, in contrast to the join_timeout, >> it is not specified that nodes can change this value. If they >> cannot change the value, why communicate it? And what should >> a node assume if it receives a value different from the >> predefined one? Fail? Report an error? Use it? >> >> Generally, it appears that the communication and use of parameters=20 >> could be a bit more elaborate. >> >> Section 9.2: >> >> "as defined in Section 5 of this draft" >> >> s/draft/document/ >> >> Sections 8 and 9, albeit defining protocol mappings, do not use the=20 >> normative language. Just checking that this is intentional. >> >> Given that section 11.4 registers these uses, I'd be leaning more=20 >> towards a normative language. >> >> Section 10: >> >> Just curious: >> >> Wouldn't an IANA-registered code point make more sense for an RFC? >> (but you have probably been through this before) >> >> Potential implications on IANA considerations. >> >> Section 11: >> >> The same can be argued for the message type. >> >> MUST not -> MUST NOT >> >> Section 17: >> >> It'd be nice if the bullets could be expanded on to explain >> further. >> >> >> >> I have not watched out for or reported on minor spelling or=20 >> punctuation since this will be captured by the RFC editor. >> >> J=F6rg >> >> > From buford@samrg.org Tue Jun 11 12:29:26 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 79F1E21F8EB3 for ; Tue, 11 Jun 2013 12:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 9--dbDFC4EDn for ; Tue, 11 Jun 2013 12:29:21 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 6D34721F8FA4 for ; Tue, 11 Jun 2013 12:29:19 -0700 (PDT) Received: (qmail 8751 invoked by uid 0); 11 Jun 2013 19:28:56 -0000 Received: from unknown (HELO host181.hostmonster.com) (74.220.207.181) by oproxy9.bluehost.com with SMTP; 11 Jun 2013 19:28:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samrg.org; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=TYqYctu/orefq/L98a8Q3vZB5/kk+LJP/fehPrxypT4=; b=f2LwXZsSImwWlzFAjX0U4ASN943TSBdK2JITYhk6ReJ2gY+BDt5k2Xmm9D3ao+NHWlDOKYaZHdqWtLDh5jW8ujqIlTH15L8OHDhzKzyFv4r9H0kdcfS334VdVFlgci32; Received: from [68.38.211.16] (port=55778 helo=Avalon) by host181.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UmUFS-0006fi-An; Tue, 11 Jun 2013 13:28:54 -0600 From: "John Buford" To: "'Eggert, Lars'" References: <517BD1B0.2060007@informatik.haw-hamburg.de> <8198246B-207B-4E98-B32B-FF57DD535270@netapp.com> <7055BE7F-C733-434B-841C-EB21A15700EA@netapp.com> <519E646D.5000608@netlab.tkk.fi> <120C2C91-FC1C-4C3D-92F5-AAB1C7590FEE@netapp.com> <519F264F.2060005@netlab.tkk.fi> <51B0AA7B.2020500@cs.stir.ac.uk> <0a4701ce66be$bfc4acc0$3f4e0640$@samrg.org> <3233657E-CA45-438E-9B3F-6B69C12E76A1@netapp.com> In-Reply-To: <3233657E-CA45-438E-9B3F-6B69C12E76A1@netapp.com> Date: Tue, 11 Jun 2013 15:28:50 -0400 Message-ID: <0a9f01ce66d9$e7df4ab0$b79de010$@samrg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGxCZyUKHndlpuT2lDY5yhpkzsWRQJ9T4PbAaxdda8Cr5L1aAHzIPiOAlzvAeYCK77McgJ98vDqAm06DyACcoH0FJjGCdbw X-Identified-User: {2055:host181.hostmonster.com:samrgorg:samrg.org} {sentby:smtp auth 68.38.211.16 authed with buford@samrg.org} Cc: 'Michael Welzl' , 'sam' , 'Internet Research Steering Group' Subject: Re: [SAM] [irsg] IRSG Poll 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: Tue, 11 Jun 2013 19:29:26 -0000 Hi Lars, Thanks. Ticket has been changed to state "IRSG review concluded". URLs to votes have been included. document type changed from Info to Experimental Latest version of document is now referenced in ticket. Thank you Michael and Joerg for your reviews. John -----Original Message----- From: Eggert, Lars [mailto:lars@netapp.com]=20 Sent: Tuesday, June 11, 2013 1:30 PM To: John Buford Cc: Dr Mario Kolberg; Joerg Ott; Internet Research Steering Group; = Thomas C. Schmidt; Michael Welzl Subject: Re: [irsg] IRSG Poll for = draft-irtf-samrg-sam-baseline-protocol-02 Hi John, On Jun 11, 2013, at 12:14, John Buford wrote: > Now that the ID has been revised per Joerg's and Michael's comments,=20 > what is the next step? with the original review by Michael and the second "ready to publish" = from J=F6rg, the IRSG poll is concluded. Please update the ticket accordingly so that it reflects this and points = to the relevant emails in the IRSG archive, and then let me know so I can initiate the RFC5742 review with the IESG. Thanks, Lars PS: The detailed process is at http://wiki.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs=3D From lars@netapp.com Tue Jun 11 13:19: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 B94DD21F901F; Tue, 11 Jun 2013 13:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.362 X-Spam-Level: X-Spam-Status: No, score=-8.362 tagged_above=-999 required=5 tests=[AWL=1.438, 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 2PAGYzRZwdMA; Tue, 11 Jun 2013 13:19:30 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A16B521F8F24; Tue, 11 Jun 2013 13:19:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,847,1363158000"; d="scan'208";a="63843004" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx12-out.netapp.com with ESMTP; 11 Jun 2013 13:19:27 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.208]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 11 Jun 2013 13:19:27 -0700 From: "Eggert, Lars" To: IESG IESG Thread-Topic: Request for RFC5742 review of draft-irtf-samrg-sam-baseline-protocol-04 Thread-Index: AQHOZuD4RwRo2+j9NUSNCwXLE/6TGA== Date: Tue, 11 Jun 2013 20:19:27 +0000 Message-ID: <9F6EF318-FEFF-467B-8D7D-BF101900F261@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="utf-8" Content-ID: <01DE9E02E91A4D47AF91AA62AD2C37E4@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-sam-baseline-protocol-04 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: Tue, 11 Jun 2013 20:19:34 -0000 SGksIElFU0cgc2VjcmV0YXJ5IChCQ0MnZWQpLA0KDQp0aGlzIGlzIGEgcmVxdWVzdCBmb3IgdGhl IElFU0cgdG8gcGVyZm9ybSBhbiBSRkM1NzQyIHJldmlldyBvZiBkcmFmdC1pcnRmLXNhbXJnLXNh bS1iYXNlbGluZS1wcm90b2NvbC0wNCBmcm9tIHRoZSBTQU1SRywgdG8gYmUgcHVibGlzaGVkIGFz IGFuIEV4cGVyaW1lbnRhbCBSRkMgb24gdGhlIElSVEYgU3RyZWFtLg0KDQpUaGlzIGRvY3VtZW50 IGhhcyBiZWVuIGFwcHJvdmVkIGZvciBwdWJsaWNhdGlvbiBieSB0aGUgSVJTRy4gU2VlIGh0dHA6 Ly93aWtpLnRvb2xzLmlldGYub3JnL2dyb3VwL2lydGYvdHJhYy90aWNrZXQvNTQgZm9yIGRldGFp bHMgb24gcHJpb3IgcmV2aWV3cy4gUGxlYXNlIGNvcHkgYWxsIGNvcnJlc3BvbmRlbmNlIHRvIHRo ZSBkb2N1bWVudCBzaGVwaGVyZCwgSm9obiBCdWZvcmQgKOKAi2J1Zm9yZEBzYW1yZy5vcmcpLg0K DQpUaGFua3MsDQpMYXJzDQoNCg== From Sebastian.Meiling@haw-hamburg.de Wed Jun 26 11:58:24 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 B2A9811E8122 for ; Wed, 26 Jun 2013 11:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 IQvH0P8csbPJ for ; Wed, 26 Jun 2013 11:58:20 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB521F9F76 for ; Wed, 26 Jun 2013 11:58:19 -0700 (PDT) Received: from dehawshub02.mailcluster.haw-hamburg.de ([141.22.200.52]) by mail6.is.haw-hamburg.de with ESMTP/TLS/RC4-MD5; 26 Jun 2013 20:58:15 +0200 Received: from dehawscas01.mailcluster.haw-hamburg.de (141.22.200.81) by DEHAWSHUB02.mailcluster.haw-hamburg.de (141.22.200.52) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 26 Jun 2013 20:58:15 +0200 Received: from [192.168.2.102] (141.22.200.55) by haw-mailer.haw-hamburg.de (141.22.200.80) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 26 Jun 2013 20:58:15 +0200 Message-ID: <51CB39C6.7030106@haw-hamburg.de> Date: Wed, 26 Jun 2013 20:58:14 +0200 From: Sebastian Meiling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "users@lists.german-lab.de" , "sam@irtf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [SAM] New HAMcast release, version 0.7 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, 26 Jun 2013 18:58:24 -0000 Hi all, a new HAMcast release is now available on-line, it's version 0.7. The software packages are released as open-source under LGPL and are ready for download at: - http://hamcast.realmv6.org/developers/wiki/download HAMcast provides a middleware for transparent group communication using heterogeneous multicast technologies. HAMcast is also a reference implementation of the common multicast API ( http://tools.ietf.org/html/draft-irtf-samrg-common-api ). Currently it supports C++ and Java and runs on Linux and MacOS X. Change-log: - new release structure, merged tools and core - new BIDIR-SAM ALM module - several bug fixes - code refinements - performance enhancements - major Java-API update - updated documentation Note, that no code changes are required to existing HAMcast enabled applications. But you may have to recompile your code as of many internal changes to the IPC. Further information on HAMcast can be found on: - http://hamcast.realmv6.org/ - http://inet.cpt.haw-hamburg.de/ If you have any questions don't hesitate to contact us or join the developers mailing-list at: - http://hamcast.realmv6.org/developers/wiki/mailinglist. Regards, Sebastian Sebastian Meiling +---------------------------------------+ Internet Technologies Group Department of Computer Science Hamburg University of Applied Sciences Berliner Tor 7, 20099 Hamburg, Germany +---------------------------------------+ Mail: sebastian.meiling@haw-hamburg.de Fon: +49 40 42875 - 8067 Fax: +49 40 42875 - 8409 Web: http://www.haw-hamburg.de/inet +---------------------------------------+