Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario
draft-ietf-savi-mix-15

Note: This ballot was opened for revision 12 and is now closed.

Alvaro Retana No Objection

(Suresh Krishnan; former steering group member) Yes

Yes ( for -12)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection (2016-11-29 for -14)
No email
send info
There are a number of acronyms that could use expansion or a reference for the first time they are used (CGA, DAD are the 2 I caught).  This will probably be caught by the RFC Editor, but help sooner might be useful.

I'm fairly certain that Joel Halpern hasn't worked at Newbridge Networks for quite a few years...

(Alissa Cooper; former steering group member) No Objection

No Objection (2016-11-29 for -14)
No email
send info
= Abstract =

The phrase "must be used" sounds too prescriptive. I think something along the following lines would be more accurate:

In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods.

(Ben Campbell; former steering group member) No Objection

No Objection (2016-11-29 for -14)
No email
send info
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

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection (2016-11-30 for -14)
No email
send info
4.  Architecture

   A SAVI device may implement ant use multiple SAVI methods.

   A SAVI device may implement and use multiple SAVI methods.

6.1.2.2.  

  2.  The target is within  configured "prefix" (or equal to "address")

  2.  The target is within  the configured "prefix" (or equal to the "address")

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection (2016-11-30 for -14)
No email
send info
Probably Ben caught them already but there are a few cases where there should be an upper letter SHOULD instead of a lower latter should.

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -14)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (2016-12-01 for -14)
No email
send info
I agree with Alissa's comment.

(Terry Manderson; former steering group member) No Objection

No Objection ( for -14)
No email
send info