[Gen-art] Gen-art review of draft-sakane-dhc-dhcpv6-kdc-option-14.txt
Alexey Melnikov <alexey.melnikov@isode.com> Fri, 23 March 2012 18:22 UTC
Return-Path: <alexey.melnikov@isode.com>
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 BCB7821F862F for <gen-art@ietfa.amsl.com>; Fri, 23 Mar 2012 11:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, 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 XhYD6BCrAYEs for <gen-art@ietfa.amsl.com>; Fri, 23 Mar 2012 11:22:30 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4593021F8629 for <gen-art@ietf.org>; Fri, 23 Mar 2012 11:22:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1332526949; d=isode.com; s=selector; i=@isode.com; bh=Pe8zpzsI7CAWRihTWe7wR7q3a1sNGncM0maGhUYGW9M=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=h5qKxHFOLvMpuSmcGUZ3dibYxFVzVvqCCfEE5uhwxcVJnw+VepMUti9yZs05Sy84itol/8 XFZE7zEaLU5VTJmbVBVk6TJAaLPjRwiVvA8pDO9YsVT0ax78ns4votQp4XhQK0ay5BCZMo Q2ojy+V2oB/l3TtvBJENuiWJSrKI9iQ=;
Received: from [192.168.1.79] (191.49.12.93.rev.sfr.net [93.12.49.191]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <T2y=YgAikiqM@rufus.isode.com>; Fri, 23 Mar 2012 18:22:29 +0000
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F6CBF66.9090802@isode.com>
Date: Fri, 23 Mar 2012 19:22:30 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Shoichi Sakane <ssakane@cisco.com>, General Area Review Team <gen-art@ietf.org>, Masahiro Ishiyama <masahiro@isl.rdc.toshiba.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Jeffrey Hutzelman <jhutz@cmu.edu>
Subject: [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: Fri, 23 Mar 2012 18:22:35 -0000
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-sakane-dhc-dhcpv6-kdc-option-14.txt Reviewer: Alexey Melnikov Review Date: 23 March 2012 IETF LC End Date: 23 March 2012 IESG Telechat date: (if known) - Summary: I think this document needs another revision before being ready for IESG review, although I don't think that changes are difficult. 1. Introduction To provide a set of IP addresses of the KDC, the Kerberos V5 specification [RFC4120] defines KDC discovery by utilizing DNS SRV records [RFC2782]. However, systems that do not employ the DNS, but do use DHCP, do exist, for example industrial systems. Some industrial systems don't use DNS because they have already had their own name spaces and their own name resolution systems, including pre- configured mapping tables for devices, rather than using FQDNs and DNS. And these systems would prefer not to employ DNS only for name resolution because adding a new server may bring a decrease in the reliability of the system, and increase the management cost of the system. Minor: I am a bit doubtful about this claim, but maybe this is just me. Many systems already depend on DNS. However, I think you might be missing out on showing another reason of why your extension might be useful: it might eliminate some DNS lookups and thus can speed-up acquisition of Kerberos credentials. 3.3. Kerberos Default Realm Name Option This option provides a default realm name of the Kerberos system. Unlike the Kerberos Realm Name Option, it is intended for a DHCPv6 server to use, and specifies the default realm name to both clients and Kerberos application servers in the Kerberos system. Major: Can you give me an example of when this option might be different from the Kerberos Realm Name Option (section 3.2)? 3.4. Kerberos KDC Option This option provides a set of configuration information about a KDC. The format of the Kerberos KDC Option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_KRB_KDC | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transport Type| Port Number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | KDC IPv6 address +---------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : realm-name : : (variable length) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Major: realm-name is not described later in this section. I think it should be removed considering that you have 2 other options for Kerberos realms already. 4. Client Operation When the client requires configuration parameters for a Kerberos system while bootstrapping, the client SHOULD put the client principal name itself into the Kerberos Principal Name Option. Minor: So this option is only ever sent from a DHCP client to a DHCP server? Section 3.1 is not clear on that. When the client requires specific information for a certain realm, the client SHOULD specify the realm name in the Kerberos Realm Name Option. Minor: This might be answering one of my questions above, but I think you should make this clear in Section 3.2. When the client requires specific information related to a certain Kerberos application server of the Kerberos system, the client SHOULD put the principal name of the server into the Kerberos Principal Name Option. Major: Is such dual-purpose use a good idea? 4.1. KDC discovery for a client 1) Initially, the client asks both DNS and Kerberos information to the DHCP server. Nit: s/to/from 6) If, as the result of (1), if the client gets both DNS and Kerberos information from the DHCP server, then the client asks Kerberos information to the DNS server. Nit: s/to/from Minor: But this (or the diagram) looks confusing to me: if the client already got both Kerberos and other information from DHCP, why should it query DNS at all? I think either your diagram is confusing, or the description below, or both. 5. Server Operation After the DHCPv6 server receives a message which is contained an Option Request Option, the information the server will provide depends on local policy. If there are no criteria on the server, the following operation is RECOMMENDED. Nit: It is not entirely clear to me what you mean by "no criteria" above. idnits reports a DownRef to RFC 6251, but this was called out during IETF LC, so no problems here.
- [Gen-art] Gen-art review of draft-sakane-dhc-dhcp… Alexey Melnikov
- Re: [Gen-art] Gen-art review of draft-sakane-dhc-… Stephen Farrell
- Re: [Gen-art] Gen-art review of draft-sakane-dhc-… Jeffrey Hutzelman
- Re: [Gen-art] Gen-art review of draft-sakane-dhc-… Alexey Melnikov
- [Gen-art] Gen-art review of draft-sakane-dhc-dhcp… Alexey Melnikov