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

Agree with the dictionary definition suggestion.

For the JoinRequest => JoinAccept,JoinReject 3-some,
we could do JoinRequest => JoinResponse with sub-types for the response
Accept,Reject

I wasn't aware that all message routing required an encoded "+1" response.

Thanks for suggestions.

John

-----Original Message-----
From: sam-bounces@irtf.org [mailto:sam-bounces@irtf.org] On Behalf Of Marc
Petit-Huguenin
Sent: Thursday, November 24, 2011 11:52 AM
To: Dr Mario Kolberg
Cc: sam
Subject: Re: [SAM] Review of draft-samrg-sam-baseline-protocol-00

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

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:
>> -----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.
>>
>>

[...]

>> 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: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7Odk0ACgkQ9RoMZyVa61dp0wCdF2Znb/RGGPDTBOKxYWqT+U+e
H4EAnjP8q8J9yjFCwdaMPy+XVHVuIzUJ
=S1qj
-----END PGP SIGNATURE-----
_______________________________________________
SAM mailing list
SAM@irtf.org
http://www.irtf.org/mailman/listinfo/sam