Subject: [Dhcpv6bis] ORO Options (MUST NOT include....)

From: Timothy Winters <[email-masked]>
Date: Mon, 23 May 2016 14:24:11 -0400

I'm working on Ticket #81.

I've added the following text.

"The Option Request option MUST NOT include the
        following options: Server Identifier, Client Identifier, IA_NA,
IA_PD, IA_TA,
        Elapsed Time, Preference, Relay Message, Authentication, Server
Unicast, Rapid Commit,
        User Class, Interface-Id, Reconfigure Message, Reconfigure Accept
Option."

One I wasn't sure about but I think can be included in Oro:

Vendor Class, Vendor-specific Information.

I couldn't find anywhere if these are allowed in ORO option.

~Tim

-- 

Timothy Winters
UNH-IOL Senior Executive, Software and IP Networking
*Please note we've moved!*
21 Madbury Rd, Suite 100, Durham, NH 03824
603-421-4987

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 23 May 2016 18:37:58 +0000

Hi Tim:

Thanks for your efforts!!

Yes, I think ORO MUST NOT include ORO. The ORO is client to server (except for Reconfigure).

Vendor-specific Information is OPTIONAL in the ORO (no point in sending if client will completely ignore). Note that there is no explicit way to communicate the Enterprise-ID of ‘requested’ items – so a client would get all configured unless there was some special server processing. There’s text to this effect in 20.17.  Vendor-specific Information Option section (of current working document).

The Vendor Class is client to server, so SHOULD NOT (MUST NOT) be in the ORO:

   This option is used by a client to identify the vendor that
   manufactured the hardware on which the client is running.

BTW: Servers MUST ignore ORO requested options that don’t make sense for the server to return (i.e., if it has no explicit logic or configuration to return the option, just skip it). Of course, servers are free to log this (either that an unexpected option was included or that they are unable to return a value).

-          Bernie

From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Timothy Winters
Sent: Monday, May 23, 2016 2:24 PM
To: [email-masked]
Subject: [Dhcpv6bis] ORO Options (MUST NOT include....)

"The Option Request option MUST NOT include the
        following options: Server Identifier, Client Identifier, IA_NA, IA_PD, IA_TA,
        Elapsed Time, Preference, Relay Message, Authentication, Server Unicast, Rapid Commit,
        User Class, Interface-Id, Reconfigure Message, Reconfigure Accept Option."

~Tim

--

Timothy Winters
Please note we've moved!

---

From: Timothy Winters <[email-masked]>
Date: Mon, 23 May 2016 14:55:22 -0400

Hi Bernie,

Thanks for the quick response, good thought with the ORO option.:)

I updated the text in the Server transmission of an Advertise to the
following:

"The server MUST include options in the Advertise message containing
configuration parameters for all of the options identified in the Option
Request option in the Solicit message that the server has been configured
to return to the client. The server MAY return additional options to the
client if it has been configured to do so."

Do you want me to call out the case of skipping options the server has not
been configured with?

~Tim

On Mon, May 23, 2016 at 2:37 PM, Bernie Volz (volz) <[email-masked]> wrote:

> Vendor-specific Information is OPTIONAL in the ORO (no point in sending if
> client will completely ignore). Note that there is no explicit way to
> communicate the Enterprise-ID of ‘requested’ items – so a client would get
> all configured unless there was some special server processing. There’s
> text to this effect in 20.17.  Vendor-specific Information Option section
> (of current working document).
>
>
>
> BTW: Servers MUST ignore ORO requested options that don’t make sense for
> the server to return (i.e., if it has no explicit logic or configuration to
> return the option, just skip it). Of course, servers are free to log this
> (either that an unexpected option was included or that they are unable to
> return a value).
>
>
>
> -          Bernie
>
>
>
> *From:* Dhcpv6bis [mailto:[email-masked]] *On Behalf Of *Timothy
> Winters
> *Sent:* Monday, May 23, 2016 2:24 PM
> *To:* [email-masked]
> *Subject:* [Dhcpv6bis] ORO Options (MUST NOT include....)
>
>
>

-- 

Timothy Winters

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 23 May 2016 18:59:18 +0000

I think that text is fine (as there is “that the server has been configured”).

From: Timothy Winters [mailto:[email-masked]]
Sent: Monday, May 23, 2016 2:55 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Dhcpv6bis] ORO Options (MUST NOT include....)

Hi Bernie,

I updated the text in the Server transmission of an Advertise to the following:

"The server MUST include options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option in the Solicit message that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so."

Do you want me to call out the case of skipping options the server has not been configured with?

~Tim

On Mon, May 23, 2016 at 2:37 PM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tim:

-          Bernie

From: Dhcpv6bis [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Timothy Winters
Sent: Monday, May 23, 2016 2:24 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dhcpv6bis] ORO Options (MUST NOT include....)

~Tim

--

Timothy Winters

--

Timothy Winters