Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-dtls-09: (with COMMENT)

[David Schinazi <[e-mail]>]

Thanks Murray! I've incorporated your feedback into
the document and posted draft-ietf-babel-dtls-10
<https://tools.ietf.org/html/draft-ietf-babel-dtls-10>.
More detailed responses inline.

David


On Sat, Jun 27, 2020 at 3:02 PM Murray Kucherawy via Datatracker <
[e-mail]> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-babel-dtls-09: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Reading the shorter document before the longer one, so I may be missing
> some
> important context here.
>
> This was pretty easy to read, so nice work.  A number of editorial
> comments and
> suggestions follow:
>
> Section 2:
>
> * "... sent over to both unicast ..." -- s/over to both/over both/, right?
>

Fixed to "can be sent to both"


> Section 2.1:
>
> * "... intervals, to avoid ..." -- remove the comma
>

I personally prefer the comma, so I'll let the RFC Editor decide this one.


> * "Nodes SHOULD drop packets that have been reordered ..." -- Why would an
> implementer not do this?  (i.e., why is it only a SHOULD?)
>

Tracking reordering like this is not a feature that is available in all
DTLS stacks.
Requiring Babel implementors to add features to DTLS stacks is not a
realistic
possibility, so we made this a SHOULD.


> Section 2.2:
>
> * "... from the Magic byte ..." -- s/Magic/magic/
>

The casing here is consistent with the definition of the Magic field:
https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-17#section-4.2


> Section 2.3:
>
> * Please expand/explain "TLV" on first use.
>

TLV is considered a well-known abbreviation by the RFC Editor:
https://www.rfc-editor.org/materials/abbrev.expansion.txt
We'll let them decide this one.


> * Just an aesthetic suggestion: In this sentence...
>
>    Since Babel over DTLS only protects unicast packets, implementors may
>    implement Babel over DTLS by modifying an implementation of Babel
>    without DTLS support, and replacing any TLV previously sent over
>    multicast with a separate TLV sent over unicast for each neighbour.
>
> ...you use "implementors", "implement", and "implementation".  Maybe this?
>
>    Since Babel over DTLS only protects unicast packets, implementors may
>    provide Babel over DTLS by using a variant of Babel
>    without DTLS support, and replacing any TLV previously sent over
>    multicast with a separate TLV sent over unicast for each neighbour.
>

I do agree that repeating "implement" isn't ideal, but I feel that it more
accurately represents what we mean. We'll defer to the RFC Editor.


> Section 2.5:
>
> * Why is the stuff in the first paragraph only SHOULD/RECOMMENDED?  (The
> answer
> may lie in the second paragraph, but I'm uncertain.)
>

Because it's not required for the correctness or security of the protocol.
For example,
we do not need to mandate where implementors save their DTLS state.


> * I suggest that Section 5 should make a backward reference to this section
> since it talks about mitigation of an attack.
>

Good point. I fixed this by moving the second paragraph to the
Security Considerations section.


> Section 2.6:
>
> * "A node MAY allow configuration options to allow ..." -- change one of
> those
> "allow"s to "permit"
>

Done.