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

[Dr Mario Kolberg <[e-mail]>]

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.