[apps-discuss] apps-team review of draft-ietf-hokey-ldn-discovery-06

Eliot Lear <lear@cisco.com> Fri, 04 February 2011 11:41 UTC

Return-Path: <lear@cisco.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A75F3A6BA1; Fri, 4 Feb 2011 03:41:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.241
X-Spam-Level:
X-Spam-Status: No, score=-110.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao0vp3z5Q3Pi; Fri, 4 Feb 2011 03:41:26 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0C51C3A68FC; Fri, 4 Feb 2011 03:41:25 -0800 (PST)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AusDABN1S02Q/khNgWdsb2JhbACEFqEXFQEBFiIkhn2XeoppkBKBJ4FpgVR2BItn
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 04 Feb 2011 11:44:50 +0000
Received: from dhcp-10-61-111-78.cisco.com (dhcp-10-61-111-78.cisco.com [10.61.111.78]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p14Bino7019428; Fri, 4 Feb 2011 11:44:49 GMT
Message-ID: <4D4BE6A4.9060801@cisco.com>
Date: Fri, 04 Feb 2011 12:44:36 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: draft-ietf-hokey-ldn-discovery@tools.ietf.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "'IESG'" <iesg@ietf.org>, IETF Discussion <ietf@ietf.org>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] apps-team review of draft-ietf-hokey-ldn-discovery-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2011 11:41:27 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-hokey-ldn-discovery
Title: The Local Domain Name DHCPv6 Option Reviewer: [your name here]
Review Date: February 2, 2011

Summary: This draft is almost ready for publication as proposed standard
and should be revised further.

This draft provides a means for DHCP clients to ascertain a domain name
for use with ERP [RFC5296].

Major Issues:

The option specified in this draft is to be used for the specific
purpose of ERP, and may not be appropriate for other uses, such as use
in a search list.  See Section 2 of RFC 5296.  Both the option name and
the text should make this clear.

While this is an Applications area review, the Security Considerations
section should still conform to the requirements of RFC-3552.


Minor Issues:

According to RFC 4282 it should be possible for an NAI realm to begin
with a digit.  Strictly speaking this is not allowed by RFC 1035, which
RFC 3315 refers to, which this document references.  As a matter of
correctness, I might simply reference RFC 4282 instead of RFC 3315.

This document also specifies a length limitation of 256 octets that does
not take into account issues raised by RFC 4282.  My recommendation
would be to either match or reference the text in RFC 4282.  FWIW, I do
not like the text in 4282 much myself, because it's rather wishy washy. 
Not sure how to fix that...

Nits:

IMHO no TOC required.

Section 5:

 DHPv6 server as a suboption of the Relay-Supplied Options option
 ^^^^^

s/DHPv6/DHCPv6/