Re: [savi] AD review of draft-ietf-savi-framework

[Jari Arkko <[e-mail]>]

Jun,

I have reviewed the new version and it looks good, but I wonder if this suggested change was missed:

>> The reason to develop SAVI method variants for each single IP address
>> configuration method, in addition to the variant that handles all IP
>> address assignment methods, is to minimize the complexity of the
>> common case:  many link deployments today either are constrained to a
>> single IP address assignment methods or, equivalently from the
>> perspective of the SAVI method, separate IP address assignment
>> methods into different IP address prefixes.  The SAVI method for such
>> links can be simpler than the SAVI method for links with multiple IP
>> address assignment methods per IP address prefix.
>>
>
> Hmm. I'm not sure I buy this. First of all, I would claim that many
> links support multiple address assignment methods. For instance, dual
> stack links typically today support SLAAC for IPv6 and DHCP for IPv4.
> And its obvious that to fly in the IETF, the SAVI solution needs to
> support multiple methods. I would just replace the above text with:
>
> To provide a complete solution, SAVI methods need to support a variety
> of address configuration mechanisms. Of course there may be different
> SAVI specifications that specify, for instance SAVI functionality for
> IPv4 and IPv6 address configuration. It is expected that SAVI methods
> can collectively support DHCP [rfc2131,rfc3315], Stateless Address
> Autoconfiguration [rfc4862 <http://tools.ietf.org/html/rfc4862>] with or
> without Secure Neighbor Discovery [rfc3971], IKEv2
> [rfc5996,rfc5739,rfc5026] and combinations thereof.

Or perhaps you disagreed with the change. In any case, I can't find a change in the new document or any discussion about this particular issue. Can you take a look?

Nevertheless, I have sent the document forward to a last call.

Jari