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

From: Donald Eastlake <[email-masked]>
Date: Mon, 7 Jan 2019 00:17:36 -0500

Hi,

Here are some comments on the draft:

Abstract and Introduction: Replace "describes" with "specifies".

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?

Last paragraph of Section 2.3: I'm not sure about "unprotected
implementation of Babel". Maybe "Babel implementation without DTLS
support". 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.

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.

Security Considerations, first sentence: Maybe "The interaction" ->
"Confidential interaction".

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.

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.

Minor wording suggestions, adopt or ignore as you choose:

Abstract and Introduction: in the first line, insert "base" before
"Babel Routing Protocol".

Section 1.2: Delete "very".

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: David Schinazi <[email-masked]>
Date: Mon, 7 Jan 2019 13:19:03 -0800

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:

> Abstract and Introduction: Replace "describes" with "specifies".

Done

> is there some other sort of verification it must do?

Done. Your change was correct.

> support".

Done.

> Also, the reference to replacing "TLV"s seems odd. Can't

Not quite, since some TLVs such as IHU wouldn't contain the same contents
sent unicast vs multicast. I've clarified the text.

> template could be included as an appendix, though that is not

I was thinking of asking IANA for early codepoint assignment once the
document has gone through WGLC.

> "Confidential interaction".

Done

> over IPv4 but the last paragraph of Section 2.1 seems to be limited to

Good point, removed mention of IPv4 here.

> 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.

> "Babel Routing Protocol".

I personally find "base" odd, I'll let my co-authors comment.

> Section 1.2: Delete "very".

Done.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 8 Jan 2019 17:27:10 -0500

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

On Mon, Jan 7, 2019 at 4:19 PM David Schinazi <[email-masked]> wrote:
> 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
>
> Not quite, since some TLVs such as IHU wouldn't contain the same contents sent unicast vs multicast. I've clarified the text.
>
>>
> I was thinking of asking IANA for early codepoint assignment once the document has gone through WGLC.
>
>>
> I think the idea was that these considerations are not normative so they were placed in an appendix to match the spirit of RFC6126.
>
>>

---

From: David Schinazi <[email-masked]>
Date: Tue, 8 Jan 2019 14:57:55 -0800

Thank you Donald, I have submitted draft-ietf-babel-dtls-03
<https://tools.ietf.org/html/draft-ietf-babel-dtls-03>.
Diff from -02 available here
<https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-03>.

David

On Tue, Jan 8, 2019 at 2:27 PM Donald Eastlake <[email-masked]> wrote:

> > Not quite, since some TLVs such as IHU wouldn't contain the same
> contents sent unicast vs multicast. I've clarified the text.
> >
> >>