Re: [savi] Ben Campbell's No Objection on draft-ietf-savi-mix-14: (with COMMENT)

"Jun Bi" <> Wed, 30 November 2016 06:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4F9D129515; Tue, 29 Nov 2016 22:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.688
X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bjLrk7Feb4GE; Tue, 29 Nov 2016 22:57:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 095801295AF; Tue, 29 Nov 2016 22:57:08 -0800 (PST)
Received: from junbi-X1-2 (unknown []) by app1 (Coremail) with SMTP id CsxvpgAnLkY3eD5YvgPtAA--.4807S2; Wed, 30 Nov 2016 14:56:55 +0800 (CST)
Date: Wed, 30 Nov 2016 14:56:55 +0800
From: Jun Bi <>
To: Ben Campbell <>, iesg <>
References: <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 174[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart261175687432_=----"
X-CM-TRANSID: CsxvpgAnLkY3eD5YvgPtAA--.4807S2
X-Coremail-Antispam: 1UD129KBjvJXoWxWw1UJrWxArWUWF4xtry7ZFb_yoWrGr1rpF W3tFW7Cr4kJr1xAwn7CF18Zr1Uu3s3Jr45Jr98Jr18A398ZF12yF4xKryFy347ArZ3G3Wj qr4Ikr1DXa45ArJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkqb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I26xC2a48xMc02F40Ex7xS67I2 xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r 1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAK zVAKj4xxMxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwV AFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv2 0xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4 v20xvaj40_Zr0_Wr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAF wI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7xUUeiWUUUUUU==
X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/
Archived-At: <>
Cc: savi-chairs <>, "" <>, savi <>, "jeanmichel.combes" <>
Subject: Re: [savi] Ben Campbell's No Objection on draft-ietf-savi-mix-14: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Nov 2016 06:57:19 -0000

Dear Ben,

Many thanks for your editorial comments!

Best Regards,

Jun Bi
From: Ben Campbell
Date: 2016-11-30 07:19
To: The IESG
CC: savi-chairs; draft-ietf-savi-mix; savi; jeanmichel.combes
Subject: [savi] Ben Campbell's No Objection on draft-ietf-savi-mix-14: (with COMMENT)
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
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
I have a few minor (non-binding) comments, and some editorial comments:
-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"?
-, 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?
- 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
-- 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.
- could use some proofreading--there are a number of grammar
errors and unclear statements.
--  "value of a know binding anchor":
-- last paragraph: What is the antecedent of "It" in "It should not
-- s/"... prevent the node to assign..."/"... prevent the node from
-- I don't understand the intent of the second to last sentence well
enough to suggest wording.
- 6.1.3: Please spell out FCFS
savi mailing list