Source Address Validation Improvement (SAVI) Framework
draft-ietf-savi-framework-06

  The Gen-ART Review by Peter McCann on 2-Nov-2011 suggests many
  editorial improvements.  Please consider them.  The review can be
  found here:

    http://www.ietf.org/mail-archive/web/gen-art/current/msg06889.html

#1) s3.2 contains the following:

  The various binding anchors differ significantly in the security they
  provide.

The binding anchors in and of themselves provide no security.  I think maybe what you're trying to say is:

  The choice of a binding anchor influences the amount of security
  SAVI can provide.

And:

  IEEE extended unique identifiers, for example, fail to
  render a secure binding anchor ...

Maybe:

  IEEE extended unique identifiers, for example, fail to
  render a unique binding anchor ...

And then later:

  Given this diversity in the security provided,

with 

  Given the diversity of binding anchors,

#2) s10: Contains:

  of forged IP addresses

shouldn't it be:

  of forged source IP addresses

#3) s10: Also contains:

   If
   binding anchor is not exclusive for each user, or is without strong
   security, addresses can still be forged.

Again, I'm not sure what it means for the binding anchor to have security.  The text in s3 talks about trying to make sure the address is unique for a give source.  I think you could delete the ", or ... ," part.

#4) s10: I'm having some trouble parsing this sentence:

   If there is
   requirement the usage of IP address must be of strong security, the
   only way is using cryptographic based authentication.

Could you just use the last sentence from the savi-threat-scope security considerations:

   The only technique to unquestionably verify source addresses of a
   received datagram are cryptographic authentication mechanisms such as
   IPsec.

- Ted Hardie also reviewed this from the privacy perspective 
and had what I think is more or less the same concern as
in my discuss.

   http://www.ietf.org/mail-archive/web/privacydir/current/msg00059.html


- general: The term "legitimate IP address" is used a good few
times, and is sort-of defined in the 1st bullet of section 3,
but a clearer definition would be good - I think you mean that
"legitimate" == "not considered a spoofed source by SAVI" and no
more, (which is fine), but it could be read to mean "authorised
by the authorities" which would give the wrong impression (I
hope:-). You might even consider inventing your own term for
this, e.g. "SAVI-legitimate" or whatever (but I'm only weakly
suggesting that, I can understand that inventing such a term
might just cause more confusion now).

- p4, maybe s/network operators/network administrators/? The
term "operator" tends to be taken to mean a specific type
of admin.

- p4, Is "on the path" right really? SAVI devices need to
be close to the host as is correctly stated elsewhere.

- p5, Is "must be verifiable" correct in point#2? I think it
would be better to say "needs to be verifiable....if SAVI is to
work"

- p6, What foes "full protection for the hosts" mean? SAVI is
not protecting the host with the source address, but rather
the network or the receiving hosts and doesn't provide "full"
protection in any sense I can understand? Maybe just end 
that sentence at "lower" is the easiest change.

- p6, Is it correct to say that it is through "assignment"
that a host becomes the "legitimate" user of a source
address for all cases? (Just checking.)

- p7, Are all of the examples of binding anchors listed in
3.2 in scope of the SAVI WG? I think it'd be good to say
which are or are not, if not all are or maybe to only list
those that are in scope.

- p11, What is a "premier check"?

- The secdir review also suggests a number of minor
changes.

     http://www.ietf.org/mail-archive/web/secdir/current/msg02960.html