SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)
draft-ietf-savi-send-11

Just nits...

---

Abstract and Introduction

   The proposed mechanism is intended to complement ingress
   filtering techniques to provide a finer granularity on the control of
   the source addresses used.

"intended to"  Well, does it, or doesn't it?

"the source address used"  By whom?

---

Section 1

   SEND SAVI is designed to be deployed in SEND networks with a minimum
   set of changes.

That would be "none" :-)
And, changes to what?

I think you mean "...with as few changes to the deployed implementations
as possible."

---

Section 2.2

   Bindings are refreshed periodically by means of secured NUD_NSOL
   message issued by the SEND SAVI device, which had to be answered by a
   valid NUD_NADV message by the node for which the binding exists.

The message had to be answered or the device had to answered?
s/answered by a/answered with a/

---

There is a lot of passive voice in the document. It is not a big problem
and I think the text can be understood, but it would be way nicer to be
precise about where the responsibility lies. Random examples from Section
2.2...

   Validated RADV messages are used to associate router authorization to
   existing bindings

   Packets with off-link source addresses are only
   forwarded if they are received from a port associated to the IPv6
   address of a router.

---

The logic in 2.4 for untrusted routers is impeccable. What is missing
is an indication of what to do! If I want to deploy exactly as described
I think you are saying I cannot use the new features described in this
document, but can continue to deploy using 3971. An extra sentence would
be helpful.

---

Very many thanks for thinking about Section 5.4.

-- Section 1 --

   Scalability of a distributed SAVI system comprised of multiple SEND
   SAVI devices is preserved by means of a deployment scenario in which
   SEND SAVI devices form a "protection perimeter".  In this deployment
   scenario, validation is only performed when the packet ingress to the
   protection perimeter.

In the first sentence, we have one of my ultra-pedantic pet peeves that no one really cares about: the correct use of "comprise" is that the whole comprises the parts (or is composed of the parts).  So, "SAVI system comprising multiple SEND SAVI devices", please.

But the second sentence is the real problem; it's not complete.  It looks like it needs "is [something]" at the end (it's only performed when the ingress [...is what...]).

-- Section 2.2 --

   For that reason, in this
   specification, only switch ports MUST be used as binding anchors.

Having that particular sentence passive makes it very odd -- the meaning feels kind of twisted.  I suggest this instead: "For that reason, implementations of this specification MUST use switch ports as their binding anchors."  (The sentence right after it makes the word "only" unnecessary, so you don't have to figure out where to put it in the sentence.)

-- Section 3 --
Not a big deal, but as Section 2 uses 2119 key words, would you consider moving this to a new Section 1.1?

-- Section 4.1 --
The entity H isn't in the diagram, and doesn't appear in the text until.the next section.  Maybe say "the host" instead?  But, actually, I found t!e whole sentence odd.  Maybe this?: "...depending on whether the host moves to a different port on the same switch, or to a different switch."

1. 
First thing I checked is the document track/title/abstract
I was surprised by "implementation" in the title for a standards track RFC
http://www.rfc-editor.org/search/rfc_search_detail.php?title=implementation&pubstatus[]=Standards+Track&std_trk=Any&pub_date_type=any
shows usage of "implementation" along with "status", "notes", "requirements", but not for a specification.
What you mean here is:
	SEND-based Source-Address Validation Specification
Or even better (and simply)
	SEND-based Source-Address Validation
Then I realized that "Implementation" comes from the SAVI WG name, and that the acronym is used a lot within the draft.
Hey, wait a minute: 
- In the 3 existing RFC titles at https://ietf.org/wg/savi/, the I stands for Improvements
- And the WG name (which we agree will eventually disappear) stands for Improvements
So not sure any longer what's the right thing to do. 
A minimal change might be to replace "implementation" by "improvements" within the document.
I'll trust the responsible AD anyway (so feel free to ignore my comment)


2.
Linked to the previous comment
OLD
   In the case the SEND SAVI device is a switch that supports customer
   VLANs [IEEE.802-1Q.2005], the SEND SAVI implementation MUST behave as
   if there was one SEND SAVI process per customer VLAN.  
NEW:
   In the case the SEND SAVI device is a switch that supports customer
   VLANs [IEEE.802-1Q.2005], the SEND SAVI specification MUST behave as
   if there was one SEND SAVI process per customer VLAN.  


3. 
OLD:
Abstract

   This memo describes SEND SAVI, a mechanism to provide source address
   validation using the SEND protocol.  

NEW:
Abstract

   This memo specifies SEND SAVI, a mechanism to provide source address
   validation using the SEND protocol. 

4.
draft-ietf-savi-framework is now RFC 7039


5. 
FCFS acronym and link to RFC 6620

 
6.
Interesting in the answer to Brian's point #2
   Section 3.2 mentions a need to configure trust anchor.  Given the proposed
   network topology needed for this document, is there any operational guidance
   that could be provided on where the trust anchors should be located?

I have a few non-blocking comments that I would like the authors to consider...

1. I support the feedback provided by Adrian and Barry.  There are many aspects of this draft that could be improved using their feedback.

2. Section 3.2 mentions a need to configure trust anchor.  Given the proposed network topology needed for this document, is there any operational guidance that could be provided on where the trust anchors should be located?

3. It is unclear in section 3.3.1 as to who is doing the processing/validating of transit packets.  I assume it is the router/switch, but it would be most helpful to explicitly mention which devices need to be involved here.

4. The Introduction could be improved by including some discussion on the relationship between the SAVI SEND approach and RFC 6620.

So I take this builds on the enormous installed base of SEND-using hosts?

+1 to Brian's point about TAs.

- Many thanks for 5.4 and for handling a lot of the
other issues that caused earlier discusses on savi
stuff from me.

- I agree with Brian's comment wrt installing trust
anchors.