Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice

SM <sm@resistor.net> Fri, 25 October 2013 17:33 UTC

Return-Path: <sm@resistor.net>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0011E81B6; Fri, 25 Oct 2013 10:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level:
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 t22FaPaCu1B2; Fri, 25 Oct 2013 10:33:39 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11311E819F; Fri, 25 Oct 2013 10:33:39 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9PHXXJs012554; Fri, 25 Oct 2013 10:33:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1382722418; bh=2Wkhy77LY9rFbF4koa1tfjCvm84er36cGWsVSMdZ21Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HCC076MAUgaNEBby5IPbFHhsJ6I6bYHEE86x4dJXdDKlZgK6di3K7hAxq6ge16lT1 oHRzM0CORbJvWKxfgsRod70QAVY+YP5XcDY/NHsrVnNKCLzmyRm4MuZtw9BiLq6WRW QRn4p9oPhWbjE6Ld52aZvloUYjQnRBWeguzQ7xZM=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1382722418; i=@resistor.net; bh=2Wkhy77LY9rFbF4koa1tfjCvm84er36cGWsVSMdZ21Q=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r7hE+4DTMs6bAG3SDzMfIUaYDgDl5KsEjEq4GTkS7AW80d0vHxWdCUUu4f5QKDisq hPSsqawtjHT/fpY3CrgC9Hg/1NB0Ncukqn0PF7MjU4vpjkQHFgVYEzfGXKeQjw2WCB H9Txnfyh8OsgIvnFDhxcKQymj2Bnmb2u8hToUR0g=
Message-Id: <6.2.5.6.2.20131025092401.0d13fed0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 25 Oct 2013 10:32:26 -0700
To: ietf@ietf.org
From: SM <sm@resistor.net>
In-Reply-To: <CALaySJJR+XXbPGtzXEAOZKNTSy_HZFh6neGUiamjPay=J1W5pQ@mail.g mail.com>
References: <20130919215457.30925.98345.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB123C933B2@xmb-aln-x02.cisco.com> <EF97C65E-A58C-4076-B737-014126786442@nominum.com> <C5E08FE080ACFD4DAE31E4BDBF944EB123C96CF3@xmb-aln-x02.cisco.com> <29DE3138-F0E6-4CCB-A8A0-AD5D975E0866@nominum.com> <F474FA9D-CDC4-4DB7-937E-1252E203749F@iii.ca> <F1C4B4FB-DD91-43E3-8A01-226237BA68CE@nominum.com> <140C3FBE-AADA-420D-ADFD-80C929AF8EC3@iii.ca> <96FD71CE-ED4F-4F43-A24A-BAC991455C56@nominum.com> <C57B9F23-F8A7-422F-BFC6-F2ABB899B03D@iii.ca> <96AD4029-F81B-4BC5-90EB-D232F0A95A1A@nominum.com> <F769CC42-F242-42E6-9B40-31C875EA0156@iii.ca> <44771FA3-5660-45CB-AE84-3458C7DA4D87@nominum.com> <63557975-9AE8-4C5C-A120-9E3C7E5C84A1@iii.ca> <A4943223-ADA7-4C3E-BF18-39756F673DB3@nominum.com> <CALaySJJR+XXbPGtzXEAOZKNTSy_HZFh6neGUiamjPay=J1W5pQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Fri, 25 Oct 2013 10:59:34 -0700
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-option-guidelines-14.txt> (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2013 17:33:41 -0000

Hello,

I took a quick look at draft-ietf-dhc-option-guidelines-14.  In Section 8:

   "FQDN imposes a number of additional failure modes and issues that
    should be dealt with:

    1.  The client must have a knowledge about available DNS servers.
        That typically means that option DNS_SERVERS is mandatory.  This
        should be mentioned in the draft that defines new option.  It is
        possible that the server will return FQDN option, but not the DNS
        Servers option.  There should be a brief discussion about it;

    2.  The DNS may not be reachable;

    3.  DNS may be available, but may not have appropriate information
        (e.g. no AAAA records for specified FQDN);"

The draft recommends using IP addresses unless there is a good reason 
to use an FQDN.  I understand that everything breaks when a FQDN 
cannot be resolved.  One of the principles which is not usually 
mentioned nowadays ia that "user applications should use names rather 
than addresses".  I'll comment quickly about the above points.

The client would have to perform DNS resolution (Item 1) for the 
system to work.  There are cases where one can get away with using IP 
addresses.

When the DNS is not reachable (Item 2) people complain.  One of the 
arguments for redundancy is that the network will keep working if a 
system fails.  A person would usually see that there is some DNS 
service which is reachable.

Item 3 is odd.  The person putting in the appropriate information 
would have to think about whether the network will support, for 
example, IPv6-only hosts.

In Section 9:

   "There is no such ambiguity in DHCPv6 (with the unfortunate exception
    of [RFC5908],which was published without following the advice provided
    during the DHC working group review, and contains many errors."

This sounds like a case of a working group doing work which is not 
part of its charter (see https://datatracker.ietf.org/wg/ntp/charter/ 
).  The approval message mentioned that "This document has received 
in-depth review from both the NTP and DHC working groups and has 
strong support for advancement". Anyway, the above text does not 
sound politically correct. :-)

Section 13 discusses about chartering requirements and advice for 
Responsible ADs.  I don't think that it belongs in a document about 
guidance to prospective DHCPv6 Option developers.

Section 22 provides advice about updating existing RFCs.  I don't 
think that it belongs in a document about DHCPv6 Option guidelines.

There is advice for authors of drafts in the Security Considerations 
section.  I'll assume that authors are a security risk. :-)

Regards,
-sm