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

From: Massimiliano Pala <[email-masked]>
Date: Tue, 02 Dec 2008 14:49:50 -0500

Hi Ralph, DHC-WG,

as discussed in Minneapolis, I published the new version (01) of the I-D about
the PKI Resource Query Protocol (PRQP) as an Experimental draft from the
PKIX WG:

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-01.txt

I would need the expertise from your WG to validate the DHCP part of the I-D.

In particular, the section that provides guidelines for the distribution of
the PRQP Server(RQA) address is B.1.

Please let me know what the next steps should be...

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                   [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Damien Neil <[email-masked]>
Date: Tue, 2 Dec 2008 12:11:37 -0800

> I would need the expertise from your WG to validate the DHCP part of  

At first glance, two issues jump out at me:

Section B.1.1 does not indicate whether the option is for DHCPv4 or  
DHCPv6.  The option code and length fields are 16 bits wide, which  
implies DHCPv6, but the examples in subsequent sections imply DHCPv4.   
DHCPv4 options encode the option code and length as a single octet  
each.  (Section B.1.1 also references RFC 3315, implying DHCPv6.)

Section B.1.1 specifies that the option contains a list of DNS names,  
but the ISC DHCP examples in section B.1.2 are for an option  
containing a list of IPv4 addresses.

                - Damien

---

From: Ralph Droms <[email-masked]>
Date: Sat, 6 Dec 2008 06:35:42 -0500

I agree with Damien's review.  Take a look at RFC 4280 for an example  
of how to write parallel definitions for an option in DHCPv4 and DHCPv6.

-  Ralph

On Dec 2, 2008, at Dec 2, 2008,3:11 PM, Damien Neil wrote:

> implies DHCPv6, but the examples in subsequent sections imply  
> DHCPv4.  DHCPv4 options encode the option code and length as a  
> single octet each.  (Section B.1.1 also references RFC 3315,  
> implying DHCPv6.)
>
> Section B.1.1 specifies that the option contains a list of DNS  
> names, but the ISC DHCP examples in section B.1.2 are for an option

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 08 Dec 2008 12:37:59 -0500

Hi Ralph and Damien,

thanks for the input, it is very useful. I was trying to take a look
at how to define the options for the example, I picked the ip-address
as, from the man page, you can specify a list of ip-address but it
does not say IPv4 only (although there is an ipv6-address...).

Shall I use the domain-list data type as specified in RFC 3361 section
3.1 instead ? Would this be a better encoding ? My idea is to use an
already-existing data-type so it would be easier for PRQP adopters.

Cheers,
Max

Ralph Droms wrote:
> I agree with Damien's review.  Take a look at RFC 4280 for an example of 
> how to write parallel definitions for an option in DHCPv4 and DHCPv6.
> 
> -  Ralph
> 

-- 

Best Regards,

	Massimiliano Pala

---

From: Ralph Droms <[email-masked]>
Date: Mon, 8 Dec 2008 13:29:16 -0500

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

- Ralph

On Dec 8, 2008, at Dec 8, 2008,12:37 PM, Massimiliano Pala wrote:

>> I agree with Damien's review.  Take a look at RFC 4280 for an  
>> example of how to write parallel definitions for an option in  
>> DHCPv4 and DHCPv6.
>> -  Ralph
>>> Section B.1.1 does not indicate whether the option is for DHCPv4  
>>> or DHCPv6.  The option code and length fields are 16 bits wide,  
>>> which implies DHCPv6, but the examples in subsequent sections  
>>> imply DHCPv4.  DHCPv4 options encode the option code and length as  
>>> a single octet each.  (Section B.1.1 also references RFC 3315,  
>>> implying DHCPv6.)
>>>
>>> names, but the ISC DHCP examples in section B.1.2 are for an  
>>> option containing a list of IPv4 addresses.
>>>
>>>              - Damien
> o 
> ------------------------------------------------------------------------
> o 
> ------------------------------------------------------------------------
>

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 08 Dec 2008 17:19:45 -0500

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:
> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Dec 2008 22:05:50 -0500

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?

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?

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.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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.

Please let me know what you think of this new version and if I
successfully
addressed your concerns :D

Cheers,
Max

> But, you'll still have to define both DHCPv4 and DHCPv6 versions of
the 
> You might want to look at 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-option-guidelines-03.
txt

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Dec 2008 07:24:16 -0500

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

- Ralph

> 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.

> Which is clearly wrong if new DHCP options are to be assigned?

Correct.  This text needs to be changed.

> 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.

- Ralph