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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Sat, 27 Jun 2020 15:02:02 -0700

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?

Section 2.1:

* "... intervals, to avoid ..." -- remove the comma

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

Section 2.2:

* "... from the Magic byte ..." -- s/Magic/magic/

Section 2.3:

* Please expand/explain "TLV" on first use.

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

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

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

Section 2.6:

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 30 Jun 2020 16:01:35 -0700

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

> https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/

Fixed to "can be sent to both"

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

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

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

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

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

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

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

> since it talks about mitigation of an attack.

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

> * "A node MAY allow configuration options to allow ..." -- change one of

Done.