[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.
- [6lo] Barry Leiba's No Objection on draft-ietf-6l… Barry Leiba via Datatracker