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

[David Schinazi <[e-mail]>]

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 <[e-mail]> wrote:

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