Subject: [Roll] Barry Leiba's No Objection on draft-ietf-roll-efficient-npdao-12: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 24 Jun 2019 06:27:29 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-roll-efficient-npdao-12: 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-roll-efficient-npdao/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(Sorry, updated to add a second substantive comment that I forgot to put in the
first time.)

I have two substantive comments:

— Section 1 —

   Further a new pro-active route invalidation message called
   as "Destination Cleanup Object" (DCO) is specified which fulfills
   requirements of an optimized route invalidation messaging.

It's a small thing, but given that this is a Standards Track document, but lots
of it is not specifying a standard, I think it would be useful to call out the
part that is.  Maybe this way?:

NEW
   Further, a new pro-active route invalidation message called
   as "Destination Cleanup Object" (DCO) is specified which fulfills
   requirements of an optimized route invalidation messaging.
   This Standards Track specification is in Section 4.
END

— Section 4.3 —
With respect to the K flag, it’s clear from the description that if you set the
K flag you expect a response and you’re likely to retry if you don’t get it. 
Cool.  It’s clear that if you don’t set the K flag you might or might not get a
reply, and are more likely to get a reply for an error.  Also cool.  What’s not
clear is whether it’s reasonable to retry if you don’t get a reply, and you
didn’t set the K flag.  I suspect that it’s not reasonable, because you didn’t
ask for a reply, and I think it would help to say that: something like, “When
the sender does not set the ‘K’ flag it is an indication that the sender does
not expect a response, and the sender SHOULD NOT retry the DCO.”

The rest is a bunch of editorial comments, but only editorial comments.

General: I’ll note that the RFC Editor will change all the section titles to
title case.  So, for example, “Invalidate routes of dependent nodes” will
become “Invalidate Routes of Dependent Nodes”.  It would not be a bad thing to
make those changes now, to save the RFC Editor the time.

— Abstract —

The abstract reads very badly to my eyes.  I think it comes from an effort to
stuff it all into one sentence.  The Introduction actually says it in two
sentences, and I think that works lots better:

   This document explains the problems
   associated with the current use of NPDAO messaging and also discusses
   the requirements for an optimized route invalidation messaging
   scheme.  Further a new pro-active route invalidation message called
   as "Destination Cleanup Object" (DCO) is specified which fulfills
   requirements of an optimized route invalidation messaging.

— Section 1 —

In “distance-vector-based routing scheme”, you need two hyphens, as shown here.

   RPL has an optional messaging in the form of DAO

Here “messaging” is a modifier, but it’s not modifying anything.  An optional
messaging *what*? — you need a noun there.  Or maybe you just need to remove
“an”, which also fixes the problem.

— Section 1.2 —

   so that the node
   changing it routing adjacencies can invalidate the previous route.

“its routing adjacencies” (possessive)

   This is needed so that nodes along the previous path can release any
   resources (such as the routing entry) it maintains

There’s a number mismatch here: “nodes” and “it maintains”.  You probably want
“they maintain”.

— Section 1.3 —

In the section title, you either need to make it not a question (“Why NPDAO Is
Important”) or change the word order to be consistent with the question (“Why
Is NPDAO Important?”).

   to better achieve resource utilization.

I think “to better optimize resource utilization” is better.

— Section 4.3 —

   DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
   uniquely identifies a DODAG.  This field MUST be present when the 'D'
   flag is set.

It’s probably not a real issue, but it seems mildly odd to me to mark it
“optional” and then say that it MUST be set sometimes.  Probably just me.  But
maybe this?:

NEW
   DODAGID: 128-bit unsigned integer set by a DODAG root that uniquely
   identifies a DODAG.  This field MUST be present when the 'D' flag is
   set and is OPTIONAL otherwise.
END

(Also in Section 4.3.4)

— Section 4.3.4 —

   If
   'K' flag is not set then the receiver of the DCO message MAY send a
   DCO-ACK to signal an error condition.

This should probably be made parallel to the description of the K flag above
(and in 4.4 bullet 4 below), and say, “especially to report an error condition.”

— Section 4.4 —

   1.  If a node sends a DCO message with newer or different information
       than the prior DCO message transmission, it MUST increment the
       DCOSequence field by at least one.  A DCO message transmission
       that is identical to the prior DCO message transmission MAY
       increment the DCOSequence field.

I’m starting this by saying that I don’t think you need to change anything
here, but given that I’ve just polled several SSAC folks, simply because I
happen to be at ICANN right now, about the specific meaning of “increment”, I
have to relate this:

All say that one can “increment by <a number>”, and that’s fine.  But we are
divided on what “increment” without a number being specified means.  Some say
it means “by one” if you don’t specify.  Others say that if you don’t specify,
then the number is, well, unspecified and can be anything.  In the text above,
you say “by at least one” the first time, which is crystal clear.  The second
time you use “increment”, you don’t specify.

Now, I’m groping here, but I wonder whether there could possibly be
interoperability trouble caused by a recipient expecting an identical DCO
message to have a DCOSequence that is the same or +1, but won’t tolerate an
increase >1.  No, probably not, probably not.  You’re right; I can’t imagine
this being a problem in practice.

Never mind.

(But if you care to, you might change “increment” to “increase” to get around
this silly babble.  Or not.  As you choose.)

I clearly have too much time on my hands.

Nit: In bullet 5, “i.e.” needs a comma in front of it, as well as behind.  Or,
better, just remove “i.e.” and the sentence works perfectly well.

— Section 4.5 —
Nits: In bullet 2, “routing table is full thus resulting in an eviction of
existing routing entry.” 1. There should be a comma before “thus”. 2. Remove
“an” before “eviction”. 3. Put that removed “an” before “existing”.  (Or,
alternatively, make it “entries”, plural.)

— Section 4.6.1 —

   Dependent nodes do not have any indication regarding if any of its
   parent nodes in turn have decided to switch their parent.

Nits: There are a couple of number problems here.  “Nodes” doesn’t match “its”
(you need “their”).  And “parent nodes” doesn’t match “their parent” (probably
“their parents”, but maybe “any of their parents”).

Similarly, the “its” in the subsequent sentence should be “their”.

And “counterproductive” is one word.

— Section 4.6.2 —
Nits: “Moreover” needs a comma after it.

In the second paragraph, “an alternate and more optimized way” should use
“alternative” instead of alternate” (the distinction matter more in UK English
than in US English).

— Section 4.6.3 —

Nits: “This documents recommends” should say “document” (singular).

“all possible parent set” should say “sets” (plural).

“requirement of synchronization” should say “requirement for synchronization”.

— Section 7 —
Nits: In the second paragraph, “if the ancestor nodes sees” should say
“ancestor” (singular).  And “Having said that” needs a comma after it.