Re: [Gen-art] Gen-art review of draft-sakane-dhc-dhcpv6-kdc-option-14.txt

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 29 May 2012 13:22 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6FB21F85C6 for <gen-art@ietfa.amsl.com>; Tue, 29 May 2012 06:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 4Z1QXQBldkKL for <gen-art@ietfa.amsl.com>; Tue, 29 May 2012 06:22:54 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 326D221F85C3 for <gen-art@ietf.org>; Tue, 29 May 2012 06:22:54 -0700 (PDT)
Received: from [192.168.1.108] (cpe-174-100-242-113.neo.res.rr.com [174.100.242.113]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q4TDMh3t002245 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 29 May 2012 09:22:48 -0400 (EDT)
References: <CBEA16C5.624A%ssakane@cisco.com> <4FC4A03E.4000700@cs.tcd.ie>
User-Agent: K-9 Mail for Android
In-Reply-To: <4FC4A03E.4000700@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Jeffrey Hutzelman <jhutz@cmu.edu>
Date: Tue, 29 May 2012 09:22:38 -0400
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, ssakane <ssakane@cisco.com>
Message-ID: <42af0731-e5c2-4143-a72f-6497ac5912ca@email.android.com>
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: General Area Review Team <gen-art@ietf.org>, Masahiro Ishiyama <masahiro@isl.rdc.toshiba.co.jp>
Subject: Re: [Gen-art] Gen-art review of draft-sakane-dhc-dhcpv6-kdc-option-14.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2012 13:22:54 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

>
>Hi,
>
>On 05/28/2012 10:01 PM, ssakane wrote:
>> All,
>> 
>> I have corresponded all you suggested, and made a new version of the
>draft.
>> But, I haven't submitted it yet.
>> 
>> Corresponding to Alexey's review, I have merged both client operation
>> and server operation into a single section: client and server
>operation
>> in order for readers to understand the operations easily.
>> And, I have improved the description of how a client gets information
>> and what kind of information a server has to reply.
>> 
>> However, I am worry that this improvement will probably take this
>draft
>> to the WG review phase again.
>> I would like to ask from you whether my improvement was good way or
>not.
>
>I'd say post the new revision and send a mail to the WG
>list summarising the changes. There's no need to note
>changes that are just to the layout of the text but if
>there are changes to the protocol (e.g. addition of a
>new MUST or something) then that's what the WG should
>see. And if nobody yells, then we can go ahead.
>
>
>> 
>> And, I also need an input from you about 4.1. KDC discovery for a
>client
>> because this behavior should be left to local matter.  I am thinking
>to
>> just remove this diagram and its description.  See my response
>corresponding
>> to Alexey's comment below.
>
>Removing it seems fine to me, but maybe you want to
>be more precise about what the administrator of the
>realm MUST do here - just saying "define the method
>for the client" isn't really clear, maybe say that
>the administrator for the realm MUST pick one as
>the preferred method for clients to use. (If that's
>what you want to say.)
>
>Jeff - if any of that is not what you prefer, please
>say so, but posting the revision and moving this along
>seems right to me.

As long as there are no changes to the protocol (bits or semantics), that seems fine.