Re: [babel] Shepherd's review of draft-ietf-babel-dtls-02

[Donald Eastlake <[e-mail]>]

Hi,

I have taken a look, including doing a diff against version -02, and
this candidate -03 of draft-ietf-babel-dtls look good to me. Please
post and I'll start a new WGLC.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [e-mail]

On Mon, Jan 7, 2019 at 4:19 PM David Schinazi <[e-mail]> wrote:
>
> Thank you for your comments, Donald. I've addressed them in this commit:
> https://github.com/jech/babel-drafts/commit/9214e3fc8947d28c41f9f7cd761f107a185d2771
>
> Please let us know what you think. We could publish the git version and restart the WGLC if you think we're ready.
>
> Thanks,
> David
>
> Detailed responses inline:
>
> On Sun, Jan 6, 2019 at 9:17 PM Donald Eastlake <[e-mail]> wrote:
>>
>> Hi,
>>
>> Here are some comments on the draft:
>>
>> Abstract and Introduction: Replace "describes" with "specifies".
>
>
> Done
>
>> Section 2.1, top of page 4, says "When a node receives a new DTLS
>> connection, it MUST verify the source IP address, and reject the
>> connection if the address is not an IPv6 link-local address." Would it
>> be correct to replace this with "When a node receives a new DTLS
>> connection, it MUST verify that the source IP address is an IPv6
>> link-local address; if it is not, it MUST reject the connection." or
>> is there some other sort of verification it must do?
>
>
> Done. Your change was correct.
>
>>
>> Last paragraph of Section 2.3: I'm not sure about "unprotected
>> implementation of Babel". Maybe "Babel implementation without DTLS
>> support".
>
>
> Done.
>
>>
>> Also, the reference to replacing "TLV"s seems odd. Can't
>> there be multiple TLVs in a message? Maybe "replacing any multicast
>> Babel routing protocol message with unicast transmission of the
>> message to each known neighbor except that neighbor discovery Hello
>> TLVs MUST still be multicast." or something like that.
>
>
> Not quite, since some TLVs such as IHU wouldn't contain the same contents sent unicast vs multicast. I've clarified the text.
>
>>
>> IANA Considerations: As are probably aware, Section 8.1.1 of RFC 6335
>> is about applying for port numbers (and service names, which would, as
>> you say, be "babel-dtls" in this case). A completed application
>> template could be included as an appendix, though that is not
>> necessary.
>
>
> I was thinking of asking IANA for early codepoint assignment once the document has gone through WGLC.
>
>>
>> Security Considerations, first sentence: Maybe "The interaction" ->
>> "Confidential interaction".
>
>
> Done
>
>> Security Considerations and rfc6126bis seem to say that Babel can run
>> over IPv4 but the last paragraph of Section 2.1 seems to be limited to
>> IPv6.
>
>
> Good point, removed mention of IPv4 here.
>
>>
>> I'm not sure why Performance Considerations is an Appendix rather than
>> a section of the main text. But I guess it's OK either way.
>
>
> I think the idea was that these considerations are not normative so they were placed in an appendix to match the spirit of RFC6126.
>
>>
>> Minor wording suggestions, adopt or ignore as you choose:
>>
>> Abstract and Introduction: in the first line, insert "base" before
>> "Babel Routing Protocol".
>
>
> I personally find "base" odd, I'll let my co-authors comment.
>
>>
>> Section 1.2: Delete "very".
>
>
> Done.