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

[Ballot comment]
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")

[Ballot comment]
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.

[Ballot 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

[Ballot comment]
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...

[Ballot comment]
= 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.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-savi-mix-12.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: savi-chairs@ietf.org, draft-ietf-savi-mix@ietf.org, savi@ietf.org, suresh.krishnan@ericsson.com, jeanmichel.combes@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SAVI for Mixed Address Assignment Methods Scenario) to Proposed Standard


The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'SAVI for Mixed Address Assignment Methods Scenario'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-11-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In networks that use multiple techniques for address assignment, the
  appropriate Source Address Validation Improvement (SAVI) methods must
  be used to prevent spoofing of addresses assigned by each such
  technique.  This document reviews how multiple SAVI methods can
  coexist in a single SAVI device and collisions are resolved when the
  same binding entry is discovered by two or more methods.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-savi-mix/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-savi-mix/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7039: Source Address Validation Improvement (SAVI) Framework (Informational - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.