<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Andale Mono; font-size: 10pt; color: #000000'>As of yesterday I am subscribed to dhcwg@ietf.org and would be happy to help in whatever way I can.<br><br><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Niall O'Reilly" <Niall.oReilly@ucd.ie><br><b>To: </b>dhcwg@ietf.org<br><b>Cc: </b>"Users of ISC DHCP" <dhcp-users@lists.isc.org><br><b>Sent: </b>Friday, January 27, 2012 6:04:29 AM<br><b>Subject: </b>Re: [dhcwg] DHCPv6 and MAC Address inclusion<br><br><br>On 26 Jan 2012, at 22:57, Ted Lemon wrote:<br><br>>> They are necessary for DHCP to function in conformance with the standard.<br>>> > So they need to exist so that they can exist? Sounds like a circular argument.<br>> <br>> The standard says "do X". If your implementation does Y, you have not implemented the standard.<br>> How is this circular? The DUID identifies the client; without it, you can't differentiate between clients.<br><br> Ted,<br><br> As you've suggested in an earlier message (to <dhcp-users@lists.isc.org>),<br> the discussion really belongs on the DHCWG list. I'm trying to move it there.<br><br> [Anyone replying may find it useful to subscribe to <dhcwg@ietf.org> first.]<br><br> I think you're missing the point. I agree with the OP that the argument<br> is circular. This is because the context of the standard is self-referential<br> and self-motivating, without regard to the need for compatibility and<br> interoperability with existing business processes, some of them in place for<br> 20 years or so. These quite commonly depend on an identifier which can be<br> obtained from a label on the outside of an as-yet-unopened carton containing <br> the device to be registered so that DHCP and other network provisioning tasks<br> can be performed. These tasks typically need to be completed in advance of<br> connection of the device, by an otherwise unaided customer, to the net.<br><br> Feature parity between IPv4 and IPv6 matters, and needs to be available <br> not just in the network, but at the business process layer. Avoiding <br> feature parity, even for an apparently good reason such as discouraging<br> non-compliance, is an approach which obstructs adoption of IPv6.<br><br><br> Best regards,<br><br> Niall O'Reilly<br> University College Dublin IT Services<br><br>_______________________________________________<br>dhcwg mailing list<br>dhcwg@ietf.org<br>https://www.ietf.org/mailman/listinfo/dhcwg<br><br></blockquote><br></div></body></html>