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.