[6lo] Barry Leiba's No Objection on draft-ietf-6lo-ap-nd-18: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Thu, 06 February 2020 05:00 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6D7120127; Wed, 5 Feb 2020 21:00:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-6lo-ap-nd@ietf.org, Shwetha Bhandari <shwethab@cisco.com>, 6lo-chairs@ietf.org, shwethab@cisco.com, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <158096520238.30570.2495789744654590019.idtracker@ietfa.amsl.com>
Date: Wed, 05 Feb 2020 21:00:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/Kz6N-2h3W5G1fvDFJMlg1IijiGY>
Subject: [6lo] Barry Leiba's No Objection on draft-ietf-6lo-ap-nd-18: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 05:00:02 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-6lo-ap-nd-18: 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-6lo-ap-nd/



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

Wow: Thanks, Ben, for the VERY thorough review, which leaves little left to
comment on.  Beyond what others have sait, I just have a minor thing or two to
add:

— Section 1 —
The second paragraph begins as though the first paragraph werent there.  You
can (and should) just begin it with, “The registration mechanism in 6LoWPAN ND
prevents”, as the definition and citation are already in the paragraph before.

   This would allow the an
   attacker to steal the address

Remove the spurious “the”.

   [RFC8505] defines an Extended Address Registration Option (EARO)
   option that allows to transport alternate forms of ROVRs

The word “option” on the second line is extra, and “allows to transport” is
poor English.  This works:

NEW
   [RFC8505] defines an Extended Address Registration Option (EARO)
   that allows the transport of alternate forms of ROVRs
END

— Section 4.3 —

   The implementation of multiple hash functions in a constrained
   devices may consume excessive amounts of program memory.  This

Make it “device” for number agreement.

— Section 4.4 —

   This allows to elide a CIPO that the 6LR
   already received, at the expense of the capability to add arbitrary
   options that would signed with a RSAO.

“This allows to elide” is poor English (“to elide” needs a subject).  You can
say, “This allows the elision of a CIPO”.  You also need “would be signed”
later in the sentence.

— Section 6 —

   A 6LN can claim any address as long as it is the first to
   make that claim.  After a successful registration, the 6LN becomes
   the owner of the registered address and the address is bound to the
   ROVR value in the 6LR/6LBR registry.

Bound for how long?  Forever?  Are unused entries ever cleaned from the
registry?  Can problems arise if stale bindings stay in the registry
indefinitely?

— Section 8.3 —
I agree with Alissa that you need to remove ‘either’ and ‘or "IESG Approval"’
from the registration policy, and just leave it as Specification Required. 
“IESG Approval” is meant to be a special case, and, in general, the IESG can
always approve a registration if needed in an exceptional circumstance.  I’ll
make that clearer in the next update to BCP 26, which I’m working on with IANA.