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

["John Buford" <[e-mail]>]

-----Original Message-----
From: Joerg Ott [mailto:[e-mail]] 
Sent: Friday, May 24, 2013 4:35 AM
To: Eggert, Lars
Cc: Internet Research Steering Group; John Buford; <[e-mail]>;
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 <[e-mail]> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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
>>
>>
>> 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?)
>>
>> Section 7.2.14:
>>
>>    Same here: make explicit where the heartbeat interval comes from.
>>
>> Section 7.2.16:
>>
>>    Since the semantics appear fixed, should one name nodes 1 and 2
>>    as src and dst?
>>
>> 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/
>>
>> 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.
>>
>> 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.
>>
>>    MUST not -> MUST NOT
>>
>> 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
>>
>>
>