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

[David Schinazi <[e-mail]>]

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.