[dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments

Michael Johnston <frenchy@quiet-like-a-panther.org> Sun, 20 January 2002 21:20 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16328 for <dhcwg-archive@odin.ietf.org>; Sun, 20 Jan 2002 16:20:12 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27494 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 16:20:16 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27424; Sun, 20 Jan 2002 16:11:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27352 for <dhcwg@optimus.ietf.org>; Sun, 20 Jan 2002 16:11:52 -0500 (EST)
Received: from quiet-like-a-panther.org (r140-248-dsl.sea.lightrealm.net [209.203.248.140]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16198 for <dhcwg@ietf.org>; Sun, 20 Jan 2002 16:11:46 -0500 (EST)
Received: (qmail 16930 invoked by uid 511); 20 Jan 2002 21:11:13 -0000
Message-ID: <20020120211113.16929.qmail@quiet-like-a-panther.org>
References: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705>
In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705>
From: Michael Johnston <frenchy@quiet-like-a-panther.org>
To: "Bernie Volz \(EUD\)" <Bernie.Volz@am1.ericsson.se>
Cc: "'Jim Bound'" <seamus@bit-net.com>, dhcwg <dhcwg@ietf.org>
Date: Sun, 20 Jan 2002 21:11:13 GMT
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit

This would work for me.  I do not really see a need for making VUID length a 
bit count versus an octet count, but it is just a shift away.
 

%%michael 


Bernie Volz (EUD) writes: 

> What about considering a variable length field for this type and adding a 16-bit length to allow the length to be specified? That way, a vendor can use what they like. The server treats it as opaque anyway. 
> 
> So, in 11.3 we could change it to be: 
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |       VUID length (in bits)   |     VUID (variable length)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                                                               .
>    .                    VUID (variable length)                     |
>    .                                                               .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    .                                                               .
>    .                  domain name (variable length)                .
>    .                                                               .
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
> 
> VUID length is the number of bits of the VUID. 
> 
> VUID is the VUID (of (VUID length + 7)/8 bytes). 
> 
> - Bernie 
> 
> -----Original Message-----
> From: Jim Bound [mailto:seamus@bit-net.com]
> Sent: Sunday, January 20, 2002 12:52 PM
> To: Michael Johnston
> Cc: Bernie Volz (EUD); dhcwg
> Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments 
> 
> 
> Infiniband spec uses 128 bit global UIDs too.  I think it makes sense to
> have a 128bit option but keep the 64bit too.   If we can just add it as
> another option which I think we can.  But we don't want to hold up the
> spec either. 
> 
> 
> /jim 
> 
> 
> On Sun, 20 Jan 2002, Michael Johnston wrote: 
> 
>> Bernie, 
>> 
>> Intel-ish systems are what I use the most, so my information is skewed in 
>> that direction.  
>> 
>> The UUIDs being used today are derived from the algorithm in this document:
>> http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt  
>> 
>> Mechanisms for retrieving (and in many cases storing) the platform UUID from 
>> (to) non-volatile storage are included in (or with) most x86PC compatible 
>> laptop and desktop systems and all Intel Itanium workstations and servers.  
>> 
>> In order to get Microsoft WHQL or Intel WfM certification all systems with 
>> network boot support must contain or generate a valid platform UUID.  
>> 
>> EFI (Extensible Firmware Interface) also requires a platform UUID.  
>> 
>> 
>> %%michael  
>> 
>> 
>> Bernie Volz (EUD) writes:  
>> 
>> > Hi: 
>> > 
>> > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). 
>> > 
>> > Do you or does anyone else have some good information about the what new systems are using for UUIDs? 
>> > 
>> > - Bernie Volz 
>> > 
>> > -----Original Message-----
>> > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org]
>> > Sent: Saturday, January 19, 2002 3:00 PM
>> > To: dhcwg
>> > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments 
>> > 
>> > 
>> > Gentles, 
>> > 
>> > For the DUID contents definition (Section 11):  
>> > 
>> > Would you be adverse to expanding the size of the VUID to 128 bits or 
>> > creating an additional type (4) for a 128 bit UUID?  
>> > 
>> > Reasoning:  
>> > 
>> > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT 
>> > change over time...".  From what I have seen, most new laptops, desktops & 
>> > workstations (especially those that come with network installed) already 
>> > contain, or have space reserved for, a 128 bit UUID that is intended to be 
>> > used to manage/track the system identity.  Why have a vendor or IT assign 
>> > yet another ID number to the system.  
>> > 
>> > Using the link-layer address is also not a unique solution.  Consider the 
>> > two cases of (1) laptops connecting to docking stations that contain network 
>> > adapters and (2) replacing defective or upgrading to new network adapters.  
>> > 
>> > 
>> > %%michael  
>> > 
>> > _______________________________________________
>> > dhcwg mailing list
>> > dhcwg@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/dhcwg
>>   
>> 
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dhcwg 
>> 

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