Subject: [SAM] Fwd: Re: [irsg] IRSG Poll for draft-irtf-samrg-sam-baseline-protocol-02

From: Dr Mario Kolberg <[email-masked]>
Date: Thu, 06 Jun 2013 16:29:21 +0100

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 <[email-masked]>
To: 	Joerg Ott <[email-masked]>
CC: 	Eggert, Lars <[email-masked]>, Internet Research Steering Group 
<[email-masked]>, John Buford <[email-masked]>, Thomas C. Schmidt 
<[email-masked]>, Michael Welzl <[email-masked]>

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.

---

From: "John Buford" <[email-masked]>
Date: Tue, 11 Jun 2013 15:12:49 -0400

-----Original Message-----
From: Joerg Ott [mailto:[email-masked]] 
Sent: Friday, May 24, 2013 4:35 AM
To: Eggert, Lars
Cc: Internet Research Steering Group; John Buford; <[email-masked]>;
Thomas C. Schmidt
Subject: Re: [irsg] IRSG Poll for draft-irtf-samrg-sam-baseline-protocol-02

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
>
> On May 23, 2013, at 20:48, Joerg Ott <[email-masked]> 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:
>>
>> Section 17:
>>    It'd be nice if the bullets could be expanded on to explain
>>    further.
>>
>>
>>
>> I have not watched out for or reported on minor spelling or 
>> punctuation since this will be captured by the RFC editor.
>>
>> Jörg
>>
>>
>

---

From: "John Buford" <[email-masked]>
Date: Tue, 11 Jun 2013 15:28:50 -0400

Hi Lars,

Thanks.  Ticket has been changed to state "IRSG review concluded".
URLs to votes have been included.
document type changed from Info to Experimental
Latest version of document is now referenced in ticket.

Thank you Michael and Joerg for your reviews.

John

-----Original Message-----
From: Eggert, Lars [mailto:[email-masked]] 
Sent: Tuesday, June 11, 2013 1:30 PM
To: John Buford
Cc: Dr Mario Kolberg; Joerg Ott; Internet Research Steering Group; Thomas C.
Schmidt; Michael Welzl

Hi John,

On Jun 11, 2013, at 12:14, John Buford <[email-masked]> wrote:
> Now that the ID has been revised per Joerg's and Michael's comments, 
> what is the next step?

with the original review by Michael and the second "ready to publish" from
Jörg, the IRSG poll is concluded.

Please update the ticket accordingly so that it reflects this and points to
the relevant emails in the IRSG archive, and then let me know so I can
initiate the RFC5742 review with the IESG.

Thanks,
Lars

PS: The detailed process is at
http://wiki.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs=