Message-ID: <rt-4.4.1-64415-1498828647-1979.45488-0-0@isc.org>
X-RT-Interface: Web
In-Reply-To: <rt-4.4.1-64415-1498811611-820.45488-0-0@isc.org>
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)
References: <RT-Ticket-45488@isc.org>
 <e394695d58899ed40f4416294c888ce7@www.isc.org>
 <rt-4.4.1-64415-1498810721-1119.45488-5-0@isc.org>
 <VI1PR07MB10698EEAAE0D34C293C5C96A87D30@VI1PR07MB1069.eurprd07.prod.outlook.com> <rt-4.4.1-64415-1498811611-820.45488-0-0@isc.org>
X-RT-Original-Encoding: utf-8
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
RT-Send-CC:
Content-Length: 711

On Fri Jun 30 08:33:31 2017, karthik.ks@nokia.com wrote:
> Benefit is in testing DHCP clients and ensure their full compliance
> with RFCs, before they're deployed in the field.

=> IMHO it is not enough to implement it. I leave this
to colleagues in the case one does not share my opinion.

> Typically, DHCP servers send the DHCP options in the same order as is
> sent by dhcpd. But there are servers which send DHCP options in a
> different order. We discovered this recently with a Cisco's DHCP
> server.

=> Kea for instance uses the increasing code order. Note the
option order does not matter with two exception for DHCPv4:
 - the dhcp-agent-options should be last
 - the END option must be the last one