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

Dr Mario Kolberg <mko@cs.stir.ac.uk> Thu, 17 November 2011 16:30 UTC

Return-Path: <mko@cs.stir.ac.uk>
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 4889E21F9918 for <sam@ietfa.amsl.com>; Thu, 17 Nov 2011 08:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 VVwOTRr83HgP for <sam@ietfa.amsl.com>; Thu, 17 Nov 2011 08:30:33 -0800 (PST)
Received: from bannock.stir.ac.uk (bannock.stir.ac.uk [139.153.12.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71421F9917 for <sam@irtf.org>; Thu, 17 Nov 2011 08:30:32 -0800 (PST)
Received: from smtp.stir.ac.uk ([139.153.13.214]) by bannock.stir.ac.uk with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <mko@cs.stir.ac.uk>) id 1RR4qe-0003sy-2L; Thu, 17 Nov 2011 16:30:00 +0000
Received: from d253090.cs.stir.ac.uk ([139.153.253.90]) by smtp.stir.ac.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <mko@cs.stir.ac.uk>) id 1RR4qd-0003gH-SV; Thu, 17 Nov 2011 16:29:59 +0000
Message-ID: <4EC53685.7080801@cs.stir.ac.uk>
Date: Thu, 17 Nov 2011 16:29:57 +0000
From: Dr Mario Kolberg <mko@cs.stir.ac.uk>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Marc Petit-Huguenin <petithug@acm.org>, sam <sam@irtf.org>
References: <4EB6CDEE.6020408@acm.org>
In-Reply-To: <4EB6CDEE.6020408@acm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-stir.ac.uk-MailScanner-ID: 1RR4qe-0003sy-2L
X-stir.ac.uk-MailScanner: Found to be clean
Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00
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" <sam.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/sam>, <mailto:sam-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/sam>
List-Post: <mailto:sam@irtf.org>
List-Help: <mailto:sam-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/sam>, <mailto:sam-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2011 16:30:34 -0000

Dear Marc,

many thanks for your review. See below for our responses:

On 06/11/2011 18:11, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
>
>
> 1. Title
>
> I do not know if the rules are different for the IRTF, but shouldn't this draft
> been called draft-irtf-samrg-sam-baseline-protocol instead?
You are correct. Title will be changed.
> 2. Section 7.2.1 "...peer id closest to and less than the GroupId"
>
> This idea of a Node-ID been close to another ID is specific to certain types of
> overlays (like the CHORD-RELOAD default), but will probably do not make sense
> for other types.  The text either need to be modified to work with any type of
> overlay, or to explicitly say that this draft is only for RELOAD overlays in
> which this make sense.
RELOAD spec states that they support unstructured overlays as well. It 
would be nice to retain that flexibility. We propose to change the text 
to: "The usual interpretation in a DHT based overlay of group_id is that 
the peer with peer id closest to and less than the group_id is the root 
of the tree. However,
other overlay types are supported."
> 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).

Will change to lowercase.
> 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.

If JoinReject is received, then no further action occurs on this request.
If JoinAccept, then JoinConfirm and JoinDecline  are the possible 
matching responses.

With these changes, then Join and JoinAccept will be treated as requests as
in RELOAD which are retransmitted until either retry limit is reached or 
a matching
response received,

> 5. Section 10.1. Data Model section
>
> The Data Model is probably SINGLE here.
> 6. Section 10.1. Access Control section
>
> The Access Control policy NODE-MATCH assumes that the Resource Name is the
> Node-ID of signer of the ALMtree entry.  If you want to use the SessionKey as
> Resource Name, you probably need to define a new Access Control policy.
This sections are currently removed from the draft.
>
> Nits
> - ----
all fixed. Thanks!

Regards,
Mario

-- 
The Sunday Times Scottish University of the Year 2009/2010
The University of Stirling is a charity registered in Scotland, 
 number SC 011159.