Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-duid-uuid-02.txt

From: Thomas Narten <[email-masked]>
Date: Thu, 06 Jan 2011 09:39:42 -0500

Hi all.

Now that the holiday break is over, some reviews of this document
would be appreciated. The WG won't advance it if there is only
silence...

It's a short document. Only about 3 pages of substance.

Thanks!

Thomas

Ted Lemon <[email-masked]> writes:

> We've been asked to do a last call on this draft; the authors
> believe that it's ready, and at least one reviewer believes so too.
> Please take this opportunity to review the draft if you have not
> already done so.  If you find problems, please discuss them here on
> the mailing list.  If you favor advancing the draft, please say so.
> If you do not want the draft to advance, please say so.  If we hear
> nothing but dead silence, the draft will not advance.

> I will be offline from 12/30/10 to 1/10/10, so I will make some
> determination as to the consensus on this draft when I get back
> online on the 10th.

> Thanks!

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Stephen Jacob <[email-masked]>
Date: Thu, 6 Jan 2011 08:55:47 -0800

The document looks good.

My only very, very minor concerns are:

 - A tiny nit! "DHCP protocol" seems repetetive

 - I have a question in my mind as to whether the security
   considerations section is even necessary given that there
   is no new additional security issue.  That same issue
   applies to any DUID, not just DUID-UUID.

Even with the above, I approve.  +1

Regards,
Stephen

On Tue, Dec 21, 2010 at 03:32:34PM -0500, Ted Lemon wrote:
> We've been asked to do a last call on this draft; the authors believe that it's ready, and at least one reviewer believes so too.   Please take this opportunity to review the draft if you have not already done so.   If you find problems, please discuss them here on the mailing list.   If you favor advancing the draft, please say so.   If you do not want the draft to advance, please say so.   If we hear nothing but dead silence, the draft will not advance.
> 
> I will be offline from 12/30/10 to 1/10/10, so I will make some determination as to the consensus on this draft when I get back online on the 10th.
> 
> Thanks!
> 

-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Tom Taylor <[email-masked]>
Date: Thu, 6 Jan 2011 13:40:55 -0500

I support advancing this draft.

On 06/01/2011 9:39 AM, Thomas Narten wrote:
> Ted Lemon<[email-masked]>  writes:
>

---

From: "Zimmer, Vincent" <[email-masked]>
Date: Thu, 6 Jan 2011 10:49:14 -0800

This will help in mapping IPV4 network boot bare-metal scenarios that formerly used option 97 of DHCP4 for machine identifier to IPV6.

Given the gap that this addresses and completeness of document, I support advancing this draft.

---

From: Thomas Huth <[email-masked]>
Date: Fri, 7 Jan 2011 11:26:42 +0100

>    applies to any DUID, not just DUID-UUID.

Since all new RFCs must have a security consideration section nowadays,
I think it is ok to have this remark there. So I would opt for keeping
this sentence.

Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Dirk Wittkopp        
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294

---

From: Thomas Huth <[email-masked]>
Date: Fri, 7 Jan 2011 12:09:43 +0100

> would be appreciated. The WG won't advance it if there is only

I now read through the document, and it sounds good to me, so I support
advancing this draft.

I just got some minor comments:

1) You're neither referencing RFC 2119 nor using the keywords from that
RFC. However, I also didn't see a lot of sentences in your document where
you need it really urgently, so you might get away without it. Anyway,
please consider using it, e.g. in the following sentences:

- "DHCP UUIDs should be persistant across system restarts ..."

- "Implementations of this specification using DUID-UUID must select a UUID
that is persistent across system restart..."

2) You might want to add a sentence like this in the beginning of your
document, to make clear where the definitions come from:

Terminology specific to IPv6 and DHCPv6 are used in the same way as is
defined in the "Terminology" sections of [RFC3315].

3) In the "Background" section, you explain the previous DUIDs again:

"Three DUIDs types have been defined previously:

   DUID-LLT -  the Link-Layer address of one of the device's network
           interfaces, concatenated with a timestamp

   DUID-EN -  an Enterprise Number plus additional information specific
           to the enterprise

   DUID-LL -  the Link-Layer address of one of the device's network
           interfaces"

In my opinion, this is too much detail here, you can simply refer to
RFC3315 instead, e.g.

Three DUIDs have been defined previously: DUID-LLT, DUID-EN and DUID-LL
(see RFC3315 for details).

4) In some sentences, you're using a lot of "would"s ... that sounds
somewhat uncertain to me, and that seems unappropriate for an RFC to me.
For example:

In some environments, a UUID-based DUID would be preferable to the other
existing DUID types.

Please consider whether you could use a more direct language in those
sentences, e.g.:

In some environments, a UUID-based DUID is preferable to the other existing
DUID types.

5) In chapter 4, you've labeled the figure with "DUID-UUID format. ." - I
think you can remove the second (or even both?) dots here. I also doubt
that you need the "Figure 1" label here, since you never reference this in
the rest of the text.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 07 Jan 2011 08:58:58 -0500

Hi Thomas.

> that is persistent across system restart..."

Personally, I prefer not using 2119 language unless there is a
compelling need. I.e., to make very clear that not doing something is
a violation of the spec.  I don't see a strong need in this
document. But if others think this is necessary, I'll make the change.

> defined in the "Terminology" sections of [RFC3315].

Will do.

> (see RFC3315 for details).

I could, but then the reader would need to go look at 3315 to
understand what info they contain. And since I talk about the how the
existing definitions are inadequate, I think it's better to include
the detail.

> In some environments, a UUID-based DUID is preferable to the other existing

I will do this.

> that you need the "Figure 1" label here, since you never reference this in

Removed the extra ".". The "figure 1" is generated automatically by
xml2rfc and may (I'm not sure) be required as part of the general RFC
format.

Thanks for the review!

Thomas

---

From: Stephen Jacob <[email-masked]>
Date: Fri, 7 Jan 2011 10:47:46 -0800

> I think it is ok to have this remark there. So I would opt for keeping

Oh, well, that is certainly a good reason. :)

Would it be appropriate to add a sentence on to the end saying "This
security concern is not new with DUID-UUID but is a concern with
all DUID types." or something?

Regards,
Stephen

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Jan 2011 18:03:33 -0500

> all DUID types." or something?

Yes.