[savi] Ben Campbell's No Objection on draft-ietf-savi-mix-14: (with COMMENT)
"Ben Campbell" <ben@nostrum.com> Tue, 29 November 2016 23:19 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: savi@ietf.org
Delivered-To: savi@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FF0129479; Tue, 29 Nov 2016 15:19:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.38.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148046155875.11650.16751209510820446492.idtracker@ietfa.amsl.com>
Date: Tue, 29 Nov 2016 15:19:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/savi/tHWv2_cApm0XlG_u--5lQOjMCNw>
Cc: savi-chairs@ietf.org, draft-ietf-savi-mix@ietf.org, savi@ietf.org, jeanmichel.combes@orange.com
Subject: [savi] Ben Campbell's No Objection on draft-ietf-savi-mix-14: (with COMMENT)
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/savi/>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2016 23:19:19 -0000
Ben Campbell has entered the following ballot position for draft-ietf-savi-mix-14: 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-savi-mix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a few minor (non-binding) comments, and some editorial comments: Substantive: -3, 7th paragraph: "... SAVI binding table should be shared..." This seems like it might deserve a SHOULD, given that it seems like one of the main points of the document. -4: Can you define (or cite a definition) for "binding anchor"? - 6.1.1: Is the "manual" method excluded from consideration here? If so, it would be helpful to explain that, and why. - 6.1.2: It's not clear to me what the title "Overwritten preferences" means. Should this be "Exceptions"? - 6.1.2.2, paragraph 6, "message should be discarded": That seems important, should the should be SHOULD? -- (same paragraph), "It is suggested to limit the rate of defense NAs to reduce security threats to the switch." Can you elaborate on that threat, or cite something that does? - 6.2: I'm a bit surprised this section doesn't prioritize the binding with the longest expiration time. Or do you assume the manual method and FCFS method do not have expirations? -8: Can you elaborate on the correlation concern? Editorial: - General: There are a number of abbreviations that should be expanded on the first use. -1, paragraph 1: s/Validaiton/Validation - 3: Is there a reason the 4th method (manual) doesn't get a place on the list? If so, it would be helpful to add text to explain why. - 5: The DHCP/SLAAC and SeND/non-SeND headings seem ambiguous, in that it is not clear to me that the "/" means "these two things in combination", as opposed to "either of these methods". I suggest writing out what you mean rather than using the "/" as a shortcut. (Also, are these the only combinations that people need to think about?) -6: I assume "assignment separation" is the method described in section 5, but that section never uses those exact words. Please consider using a consistent term. -6.1.1, first paragraph "decide to whom" Does this mean to decide which binding anchor to use? (Otherwise, who is "whom"?) -- The use of a numbered list in 6.1.1 seems to imply some ordering or preference, but I don't think that is the intent. If so, please consider using an non-numbered list. - 6.1.2.2 could use some proofreading--there are a number of grammar errors and unclear statements. -- "value of a know binding anchor": s/know/known -- last paragraph: What is the antecedent of "It" in "It should not install..." -- s/"... prevent the node to assign..."/"... prevent the node from assigning..." -- I don't understand the intent of the second to last sentence well enough to suggest wording. - 6.1.3: Please spell out FCFS