Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00

Marc Petit-Huguenin <> Thu, 24 November 2011 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF74021F8BD5 for <>; Thu, 24 Nov 2011 08:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.603
X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b7cNNJK+zvDp for <>; Thu, 24 Nov 2011 08:52:51 -0800 (PST)
Received: from ( [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by (Postfix) with ESMTP id 0EF5F21F8BBB for <>; Thu, 24 Nov 2011 08:52:51 -0800 (PST)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] ( [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "" (verified OK)) by (Postfix) with ESMTPS id 424A920142; Thu, 24 Nov 2011 16:42:17 +0000 (UTC)
Message-ID: <>
Date: Thu, 24 Nov 2011 08:52:30 -0800
From: Marc Petit-Huguenin <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Dr Mario Kolberg <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: sam <>
Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
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, 24 Nov 2011 16:52:52 -0000

Hash: SHA1


More comments below.

On 11/17/2011 08:29 AM, Dr Mario Kolberg wrote:
> Dear Marc,
> many thanks for your review. See below for our responses:
> On 06/11/2011 18:11, Marc Petit-Huguenin wrote:
>> Hash: SHA1
>> Sorry for the delay in reviewing this.  I waited to base the review on an
>> implementation, but unfortunately I never got the time to do so.  So this is
>> only a partial review.


>> 3. Section 7.2.1 structure definition
>> The Dictionary type is not defined in this spec.
>> Also I would suggest to follow the standard convention of using lowercase for
>> the character of a field.
> Reload defines DictionaryEntry (section 6.2.3). Dictionary is a 'data model'
> (section 6.2).

But Dictionary is never defined as a data structure in RELOAD, and even if it
was defined as an array of DictionaryEntry, that would not match the text
("name-value list of properties...") - the closest structure definition that
matches this text in RELOAD would be IceExtension.

I would suggest to explicitly define Dictionary as follow:

struct {
  opaque name<0..2^16-1>;
  opaque value<0..2^16-1>;
  } DictionaryElement;

struct {
  DictionaryElement elements<0..2^16-1>;
  } Dictionary;

>> 4. Section 7.2.[2-5]
>> RELOAD message are client/server based.  A request is sent and retransmitted
>> until a matching response is received.  I am sure how the
>> Join/JoinAccept/JoinConfirm/JoinDecline mechanism is working inside this
>> framework.
> For Join,  JoinAccept and JoinReject  are matching responses.

But this is not how the RELOAD routing works.  RELOAD says that a response uses
the code value + 1 of the request, excepted for the ErrorResponse.  The problem
here is that a standard implementation of RELOAD will not be able to process
correctly theses messages.  If the goal is to change the routing algorithm, I
would suggest to add a ForwardingOption to each message, with the
FORWARD_CRITICAL flag set, so standard RELOAD implementations do not even try to
route these.


- -- 
Marc Petit-Huguenin
Personal email:
Professional email:
Version: GnuPG v1.4.11 (GNU/Linux)