Re: [dhcwg] PKIX WG new I-D draft: DHCP section review

Ralph Droms <rdroms@cisco.com> Wed, 24 December 2008 12:24 UTC

Return-Path: <dhcwg-bounces@ietf.org>
X-Original-To: dhcwg-archive@megatron.ietf.org
Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11353A6B64; Wed, 24 Dec 2008 04:24:30 -0800 (PST)
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9BC3A6B64 for <dhcwg@core3.amsl.com>; Wed, 24 Dec 2008 04:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.246
X-Spam-Level:
X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 3uoPgUh8ifYI for <dhcwg@core3.amsl.com>; Wed, 24 Dec 2008 04:24:28 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0F85F3A6B6A for <dhcwg@ietf.org>; Wed, 24 Dec 2008 04:24:27 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.36,278,1228089600"; d="scan'208";a="31984898"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Dec 2008 12:24:18 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBOCOIcB023467; Wed, 24 Dec 2008 07:24:18 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mBOCOIYv009093; Wed, 24 Dec 2008 12:24:18 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 07:24:18 -0500
Received: from bxb-rdroms-8717.cisco.com ([10.98.10.88]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Dec 2008 07:24:17 -0500
Message-Id: <2D21FDF6-7BF2-4051-BAA0-442177603393@cisco.com>
From: Ralph Droms <rdroms@cisco.com>
To: Bernie Volz <volz@cisco.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB2109E4323F@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Wed, 24 Dec 2008 07:24:16 -0500
References: <4935915E.1060708@Dartmouth.edu><F32C8732-944D-4DB4-9E39-FF4430973C1A@nominum.com><A29FB4BE-EDEC-4BD8-B2A4-DE340BAB6A84@cisco.com><493D5B77.1050708@Dartmouth.edu><52028AF8-6F1E-430A-8A52-19ECEE1ADDD6@cisco.com> <493D9D81.4090301@Dartmouth.edu> <8E296595B6471A4689555D5D725EBB2109E4323F@xmb-rtp-20a.amer.cisco.com>
X-Mailer: Apple Mail (2.930.3)
X-OriginalArrivalTime: 24 Dec 2008 12:24:18.0067 (UTC) FILETIME=[8AA17E30:01C965C2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2993; t=1230121458; x=1230985458; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20<rdroms@cisco.com> |Subject:=20Re=3A=20[dhcwg]=20PKIX=20WG=20new=20I-D=20draft =3A=20DHCP=20section=20review |Sender:=20 |To:=20Bernie=20Volz=20(volz)=20<volz@cisco.com>; bh=/oQIOMyVK2yZTGb7ZgHkq4JTBZFrnlZFe0t0P9dLxGI=; b=nR7DmDYk40a7I+lNV7WRrRlwXejxw0lDMUiQOkmio2ZV8yuIrzFnehZ4xZ hItktc+VPO/rMHY+OQpbOLyepxmK92A14FwM/bRu4KlSJejef8kMRiKo6P7d fEj3rH/ynD;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: DHC-WG WG <dhcwg@ietf.org>, Massimiliano Pala <Massimiliano.Pala@Dartmouth.edu>, Damien Neil <Damien.Neil@nominum.com>
Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

Bernie - thanks for your review; responses in line...

- Ralph

On Dec 9, 2008, at 10:05 PM, Bernie Volz (volz) wrote:

> While the DHCP(v4+v6) option definitions are now much better (in  
> 02), I
> wonder whether this will fly.
>
> Can new options be defined in an Appendix of an RFC?

Good questions.  RFC 2939 does not preclude the definition of new  
options in an Appendix.  Neither does RFC 2939 preclude the definition  
of new options in an Experimental RFC.

> There's no IANA directives in the draft to request IANA to assign  
> codes
> for these options? In fact:
>
> 5.  IANA Considerations
>
>   This document has no actions for IANA.
>
> Which is clearly wrong if new DHCP options are to be assigned?

Correct.  This text needs to be changed.

> Also, while DHCPv6 has plenty of "available" option numbers, DHCPv4
> doesn't have as many. I wonder whether if this is truly experimental,
> that a Vendor Specific Information Option (for both v4 + v6) might not
> be better? You would need to get an Enterprise-ID if you don't already
> have one. If all depends on how widely this is to be implemented (ie,
> how experimental is it?).
>
> If 'real' IANA assigned options are desired, the Appendix/IANA
> cosniderations issues are more likely for the AD to address? Or you
> might want to see what other Experimental RFCs have done in terms of  
> new
> definitions for IANA maintained registries.

As a practical matter, pressure on the DHCPv4 option code space has  
been reduced with the expansion of the list of available options and a  
slowdown in the rate of defining new options.  I don't think assigning  
a DHCPv4 option code for this option is problematic.  I agree that the  
Vendor-identifying Vendor Specific Option might be a good way to  
finesse the problem.

> - Bernie

- Ralph

>
>
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf
> Of Massimiliano Pala
> Sent: Monday, December 08, 2008 5:20 PM
> To: Ralph Droms (rdroms)
> Cc: DHC-WG; Damien Neil
> Subject: Re: [dhcwg] PKIX WG new I-D draft: DHCP section review
>
> Hi Ralph,
>
> that was kinda not clear to me - I thought that I did not need to  
> define
> two different options for DHCPv4 and DHCPv6. I just uploaded the new
> version
> of the draft where I defined the PRQP server option for DHCPv4 and
> DHCPv6.
>
> The new draft is published as:
>
>    http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-02.txt
>
> Please let me know what you think of this new version and if I
> successfully
> addressed your concerns :D
>
> Cheers,
> Max
>
> Ralph Droms wrote:
>> You could choose either IP addresses or FQDNs for the option payload.
>
>> But, you'll still have to define both DHCPv4 and DHCPv6 versions of
> the
>> option.
>>
>> You might want to look at
>>
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-03 
> .
> txt
>

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