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

"Jun Bi" <junbi@tsinghua.edu.cn> Mon, 26 September 2011 17:50 UTC

Return-Path: <junbi@tsinghua.edu.cn>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E17111E80D3 for <savi@ietfa.amsl.com>; Mon, 26 Sep 2011 10:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.803
X-Spam-Level:
X-Spam-Status: No, score=-99.803 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up36IXJ47Z6w for <savi@ietfa.amsl.com>; Mon, 26 Sep 2011 10:50:34 -0700 (PDT)
Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 540E211E80CD for <savi@ietf.org>; Mon, 26 Sep 2011 10:50:34 -0700 (PDT)
Received: from th024128.ip.tsinghua.edu.cn ([59.66.24.128] helo=junbiVAIOz138) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from <junbi@tsinghua.edu.cn>) id 1R8FMg-0002lP-QD; Tue, 27 Sep 2011 01:53:14 +0800
Message-ID: <AB85F5C3CD304A05AD3C08C59E000F97@junbiVAIOz138>
From: Jun Bi <junbi@tsinghua.edu.cn>
To: Jari Arkko <jari.arkko@piuha.net>, Jun Bi <junbi@cernet.edu.cn>, SAVI Mailing List <savi@ietf.org>
References: <4DDC19D4.2040104@piuha.net> <4E7FE358.50509@piuha.net>
In-Reply-To: <4E7FE358.50509@piuha.net>
Date: Tue, 27 Sep 2011 01:53:17 +0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"; reply-type="response"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109
Subject: Re: [savi] AD review of draft-ietf-savi-framework
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2011 17:50:35 -0000

Hi Jari,

I think we missed your comment is good and your text below is perfect.
Then how can we proceed now? (we replace the text and submit a new version?)

thanks,
Jun Bi

-----原始邮件----- 
From: Jari Arkko
Sent: Monday, September 26, 2011 10:28 AM
To: Jun Bi ; SAVI Mailing List
Subject: Re: [savi] AD review of draft-ietf-savi-framework

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

_______________________________________________
savi mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi