Subject: Re: [Gen-art] Fwd: Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08

From: 包丛笑 <[email-masked]>
Date: Fri, 3 Oct 2014 10:46:53 +0800 (CST)

Hi, 

My answers are in the lines:

> -----原始邮件-----
> 发件人: "Suresh Krishnan" <[email-masked]>
> 发送时间: 2014年10月1日 星期三
> 收件人: "[email-masked]" <[email-masked]>
> 抄送: 
> 主题: Fwd: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08
> 
> Hi Folks,
>    Please take a look at this review and respond. Ted already responded 
> partially to the review. Continue with a response to the open points.
> 
> Thanks
> Suresh
> 
> -------- Forwarded Message --------
> Subject: [Gen-art] Gen-ART Last Call review of 
> draft-ietf-softwire-map-dhcp-08
> Date: Mon, 29 Sep 2014 14:00:34 +1300
> From: Brian E Carpenter <[email-masked]>
> Organization: University of Auckland
> To: [email-masked], General Area Review 
> Team <[email-masked]>
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-softwire-map-dhcp-08.txt
> Reviewer: Brian Carpenter
> Review Date: 2014-10-29
> IETF LC End Date: 2014-10-10
> IESG Telechat date:
> 
> Summary:  On the right track
> --------
> 
> Major Issues:
> -------------
> 
> [I-D.ietf-softwire-map], [I-D.ietf-softwire-map-t] and 
> [I-D.ietf-softwire-lw4over6]
> are listed as Informative references. I find it hard to see how an 
> implementer can
> implement the DHCPv6 options without consulting those documents, so IMHO they need to be Normative references.
> 
> For example, in section 4.5 we find
> 
> >  See [I-D.ietf-softwire-map], Section 5.1 for a description of MAP
> >  algorithm, explaining all of the parameters in detail.
> 
> I have the same concern for [I-D.ietf-softwire-unified-cpe] when I see
> 
> > [I-D.ietf-softwire-unified-cpe]
> >  describes client behaviour for the prioritization and handling of
> >  multiple mechanisms simultaneously.
> 
> I don't see an implementer can develop a generic client without 
> consulting that
> document too.

Agree to list [I-D.ietf-softwire-map], [I-D.ietf-softwire-map-t] and [I-D.ietf-softwire-lw4over6] as normative references.

> In section 4.1:
> 
> > Clients MUST NOT send an OPTION_S46_RULE option.
> 
> What happens if they do?

We may add a sentence states that “It is an invalid option, if received by server, discard.”

> 
> >  o  F-Flag: 1 bit field that specifies whether the rule is to be used
> >     for forwarding (FMR).  If set, this rule is used as a FMR, if not
> >     set this rule is a BMR.  Note: A BMR rule can also be an FMR rule
> >     by setting the F flag.  The BMR rule is determined by a match of
> >     the Rule-IPv6-prefix against the CPE's prefix(es).
> 
> The logic of the third sentence is so strange that I can't deconstruct it.
> Maybe it just means "An FMR can also be used as a BMR." If so, please 
> just say
> it. If not, I'm baffled.

Suggest add a sentence states that 
“For the mesh scenario, set the Fflag (It means that BMR is also FMR).
For the hubs&spokes scenario, do not set the Fflag (It means that there is no FMR).”

> 
> Also, in the last sentence, is that an exact match or a longest match?

It is the exact match to get the EA-bits. Refer to “Figure 3: MAP IPv6 Address Format” in [I-D.ietf-softwire-map].

> Are the CPE's prefix(es) the one(s) it uses for its own address(es)
> or the ones it can delegate to the customer network?
> 
> (I suspect this paragraph is one of the cases that requires the drafts
> mentioned above to be normative references. As written, it is virtually
> impossible to understand.)
> 
> In section 4.5:
> 
> There are two references to "the softwire node". Does that mean the CE?
> In fact, I think you need some scoping text in the Introduction. I 
> assume that
> "DHCPv6 client", "CE", "CPE" and "the softwire node" all mean the same 
> thing;
> if so, please be consistent on terminology.  I also assume that these DHCPv6
> options must only be used by a DHCPv6 client which is also a C(P)E and
> a softwire node. It would be nice to know that from the start.

Agree to unify the terminology. We may add a “Terminology section” similar to the ones in [I-D.ietf-softwire-map] (Section 3).

Regards

Congxiao

> Minor issues:
> -------------
> 
> To avoid a long discussion with the RFC Editor about the number of authors,
> please consider having one author tagged as Editor and the rest as a list of
> Contributors, as described in RFC 7322.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Oct 2014 16:39:16 +1300

Hi Congxiao,

Thankyou for the replies. I think all those changes are good (just
have someone check the English).

For the references it is your choice. Ted did not agree with me!

Regards
   Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 3 Oct 2014 07:52:25 -0400

> We may add a sentence states that “It is an invalid option, if received by server, discard.”

Please do not add such a sentence.   Rather, please add a sentence that says:

This option has no meaning when sent from client to server.  However, servers may take options sent by clients as a hint for what values to return, so clients MUST NOT send this option to servers.

You cannot modify server behavior in a new option specification document.   Please see RFC 7227 for details.

---

From: 包丛笑 <[email-masked]>
Date: Sat, 4 Oct 2014 09:16:13 +0800 (CST)

Hi Brian,

Thank you.

Congxiao

> -----原始邮件-----
> 发件人: "Brian E Carpenter" <[email-masked]>
> 发送时间: 2014年10月3日 星期五
> 收件人: "包丛笑" <[email-masked]>
> 抄送: "Suresh Krishnan" <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
> 主题: Re: Fwd: [Gen-art] Gen-ART Last Call review of draft-ietf-softwire-map-dhcp-08
> 
> Hi Congxiao,
>

---

From: 包丛笑 <[email-masked]>
Date: Sat, 4 Oct 2014 09:18:08 +0800 (CST)

Hi Ted,

Agree with you,  "clients MUST NOT send this option to servers."

What I mean in the previous mail is that "if a misconfigured client sends this option to server, the server MUST ignore it". 

Yes, server MUST behave according to RFC7227. 

Thanks.

Congxiao

---

From: 包丛笑 <[email-masked]>
Date: Sat, 4 Oct 2014 12:16:50 +0800 (CST)

Hi Ted ,

Thanks for your suggested wording, I am happy to use it as the text:

"This option has no meaning when sent from client to server.  However, servers may take options sent by clients as a hint for what values to return, so clients MUST NOT send this option to servers."

Thanks.

Congxiao

---

From: Tomek Mrugalski <[email-masked]>
Date: Sat, 04 Oct 2014 12:38:28 +0200

On 29/09/14 04:24, Brian E Carpenter wrote:
> On 29/09/2014 14:19, Ted Lemon wrote:
>> Hm.   I am a bit puzzled.   These are DHCP options.   This document
>> just says what the format of the options is.   Do you really think
>> the DHCP server implementor needs to understand that in order to
>> follow this document?
> 
> I was thinking of the client side. I could be wrong though. It
> depends on how the client side is implemented, I guess: it could just
> be a DHCPv6 engine that is blind to the content of the options, which
> it passes on to the softwire code.
This is how many DHCP clients and servers are implemented these days.
You can define extra options that a client can request and a server can
send back. The received options are not interpreted by the client
engine, but passed to a script. In that sense, many implementations
allow adding support for new options (on both server and client) without
even recompiling (or releasing new software version).

So it really depends on what part of the task you consider a 'client
implementation'. If you strictly limit to the DHCP software, informative
reference is sufficient. If you also consider how the options are
supposed to be used, then the reference should be normative.

As a DHCP implementor, informative would be more appropriate for me. But
CPE implementors that integrate the software need normative references.

Anyway, I'm fine with either way.

Tomek

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Oct 2014 07:58:57 +1300

> Anyway, I'm fine with either way.

So am I, really, as long as the people involved have thought about it.
You might prefer the references to be RFCs rather than "work in progress"
though; if you make them normative, that will be the result.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Oct 2014 10:36:08 +0200

> This option has no meaning when sent from client to server.  However, servers may take options sent by clients as a hint for what values to return, so clients MUST NOT send this option to servers.

hmm. that's actually an interesting point. does it harm to allow this to be a hint to the server?
if that how DHCP servers generally work?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Oct 2014 10:39:00 +0200

Brian,

> though; if you make them normative, that will be the result.

there is a lot of history here. these were made informative when it was very unclear what publication path they different documents would follow, or if they would be published at all. we tried to lessen interdependencies as much as possible.

now that it all documents in the series will be published together, I think it is cleaner with normative cross references.

cheers,
Ole

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 10 Oct 2014 10:39:24 +0200

> if that how DHCP servers generally work?
Some implementations are able to look at the values sent by the client,
but it's unlikely that such behavior would work for MAP, unless coded
for it explicitly.

Still, that may be a nice feature if it makes sense for the client to
makes suggestions, MAP wise.

I'm ok with tweaking the text to allow it, but the text must by clear
that that's just a hint, the server may ignore it completely and the
client must use whatever it receives.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Oct 2014 10:42:58 -0400

> if that how DHCP servers generally work?

The problem is that the client might supply a wrong hint.   I am not aware of any DHCP servers that actually support this kind of hinting, but it is allowed in the spec.   I argued against it, but lost.   :}

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Oct 2014 08:01:03 +1300

Hi,

I believe I'm happy with all this. I am supposed to repeat
my Gen-ART review immediately, for the imminent IESG meeting.
If you get the -09 draft out promptly that would be great.

Regards
   Brian

On 10/10/2014 21:53, Ole Troan wrote:
> Brian,
> 
> thank you very much for a thorough review.
> combined with Ted's AD review there are quite a few changes.
> can you look over the attached diffs, and let us know if that is acceptable?
> I've tried to combine the suggestions made by Ian and Congxiao.
> 
> Best regards,
> Ole
> 
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 10 Oct 2014 21:03:36 +0200

On 10/10/14 16:42, Ted Lemon wrote:
>> hmm. that's actually an interesting point. does it harm to allow
>> this to be a hint to the server? if that how DHCP servers generally
>> work?
> 
> The problem is that the client might supply a wrong hint.   I am not
> aware of any DHCP servers that actually support this kind of hinting,
> but it is allowed in the spec.   I argued against it, but lost.   :}
Dibbler is able to take hints and use them if it's allowed by the server
configuration. But it's working only for some options. Anyway, that's a
feature that was codified in RFC3315, so new options are bound to it.

Here's proposed update. I tried to avoid any normative language here.
The only exception is to be very explicit that this is a hint only and
server may send something completely different. It's similar to the
prefix length hints in PD. Some implementors didn't get that right in PD
and there are all sorts of odd behaviours observed out there.

OLD:
   A server MAY send more than one OPTION_S46_RULE option in a
   container, if it is configured to do so. This option has no
   meaning when sent from client to server. However, servers may
   take options sent by clients as a hint for what values to
   return, so clients MUST NOT send this option to servers.
NEW:
   This option follows behavior described in Sections 17.1.1
   and 18.1.1 of RFC3315. Clients can insert
   those options with specific values as hints for the
   server. Depending on the server configuration and policy,
   it may accept or ignore the hints. Client MUST be able
   to process received values that are different than the
   hints it sent.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 10 Oct 2014 21:08:17 +0200

> If you get the -09 draft out promptly that would be great.
Sure. Will do that in the next 24 hours.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Oct 2014 15:32:36 -0400

>   to process received values that are different than the

What guidance would you give the client as to what hints to send?   How would you avoid having the server do the wrong thing with hints based on stale data?   This is why I think the "client hints" thing in 3315 is a mistake.   I simply don't see how you can support this in any interoperable way.   Supporting it at all is not likely to do anything, because both sides have to support it, but if they do, there's no way to predict whether it will actually work, because we have never said _how_ it works.   So I am against specifying it this way; rather, this document should forbid the client sending it, so that if a server that implements this mistake is used, nothing bad will happen.

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Oct 2014 10:49:18 +0200

> Agree to unify the terminology. We may add a “Terminology section” similar to the ones in [I-D.ietf-softwire-map] (Section 3).

would something like:

   This document describes a set of common DHCPv6 options for
   configuring the MAP-E [I-D.ietf-softwire-map], MAP-T
   [I-D.ietf-softwire-map-t] and Lightweight 4over6
   [I-D.ietf-softwire-lw4over6] mechanisms.  For definition of the
   terminology used in this document please see the relevant terminology
   sections in the above references.

work?
in the S46 Overview section.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 10 Oct 2014 10:53:33 +0200

Brian,

Best regards,
Ole

diff --git a/draft-ietf-softwire-map-dhcp.xml b/draft-ietf-softwire-map-dhcp.xml
index 64d76cd..134e5d4 100644
--- a/draft-ietf-softwire-map-dhcp.xml
+++ b/draft-ietf-softwire-map-dhcp.xml
@@ -254,12 +254,16 @@
       target="RFC2119"></xref>.</t>
     </section>
 
+
     <section title="Softwire46 Overview">
 
      <t>This document describes a set of common DHCPv6 options for
-     configuring the MAP-E <xref target="I-D.ietf-softwire-map"/>, MAP-T
-     <xref target="I-D.ietf-softwire-map-t"/> and Lightweight 4over6 <xref
-     target="I-D.ietf-softwire-lw4over6"/> mechanisms.</t>
+     configuring the MAP-E <xref target="I-D.ietf-softwire-map"/>,
+     MAP-T <xref target="I-D.ietf-softwire-map-t"/> and Lightweight
+     4over6 <xref target="I-D.ietf-softwire-lw4over6"/>
+     mechanisms. For definition of the terminology used in this
+     document please see the relevant terminology sections in the
+     above references.</t>
 
      <t>MAP-E, MAP-T and Lightweight 4over6 are essentially providing
      the same functionality: IPv4 service to a CE router over an IPv6
@@ -295,9 +299,11 @@
      <t>This approach implies that all of the provisioning options
      MUST appear only within the container options. The client MUST
      NOT request any of the provisioning options directly within an
-     ORO. Likewise, the server MUST NOT send the provisioning options
-     directly within a DHCPv6 message, without encapsulation in the
-     corresponding container option.</t>
+     ORO. MAP-DHCP clients that receive provisioning options that are
+     not encapsulated in container options MUST silently ignore these
+     options.  DHCP server administrators are advised to ensure that
+     DHCP servers are configured to send these options in the proper
+     encapsulation.</t>
 
      <t>The document is organized with the common sub-options
      described first, followed by the three container options. Some
@@ -333,8 +339,11 @@
         Basic Mapping Rule (BMR) and Forwarding Mapping Rule
         (FMR).</t>
 
-        <t>A server MAY send more than one OPTION_S46_RULE option in a container, if it is
-        configured to do so. Clients MUST NOT send an OPTION_S46_RULE option.</t>
+        <t>A server MAY send more than one OPTION_S46_RULE option in a
+        container, if it is configured to do so. This option has no
+        meaning when sent from client to server. However, servers may
+        take options sent by clients as a hint for what values to
+        return, so clients MUST NOT send this option to servers.</t>
 
         <figure align="center" anchor="img-option-rule"
                 title="S46 Rule Option">
@@ -387,10 +396,11 @@
             <t>prefix6-len: 8 bits long field expressing the length
             of the IPv6 prefix specified in the rule-ipv6-prefix field.</t>
 
-            <t>ipv6-prefix: a variable length field that specifies the
-            IPv6 domain prefix for the S46 rule. The field is padded with
-            follow up zero bits up to the nearest octet boundary when
-            prefix6-len is not divisible by 8.</t>
+	    <t>ipv6-prefix: a variable length field that specifies the
+	    IPv6 domain prefix for the S46 rule.  The field is padded
+	    on the right with zero bits up to the nearest octet
+	    boundary when prefix6-len is not evenly divisible by
+	    8.</t>
 
 	    <t>S46_RULE-options: a variable field that may contain
 	    zero or more options that specify additional parameters
@@ -413,11 +423,12 @@
             <t>Reserved: 7-bits reserved for future use as flags.</t>
 
 	    <t>F-Flag: 1 bit field that specifies whether the rule is
-	    to be used for forwarding (FMR).  If set, this rule is
-	    used as a FMR, if not set this rule is a BMR. Note: A BMR
-	    rule can also be an FMR rule by setting the F flag. The
-	    BMR rule is determined by a match of the Rule-IPv6-prefix
-	    against the CPE's prefix(es).</t>
+	    to be used for forwarding (FMR). If set, this rule is used
+	    as a FMR, if not set this rule is a BMR only and MUST NOT
+	    be used for forwarding. Note: A BMR can also be used as
+	    an FMR for forwarding if the F-flag is set. The BMR rule
+	    is determined by a longest-prefix match of the
+	    Rule-IPv6-prefix against the End-User IPv6 prefix(es).</t>
           </list></t>
 
         <t>It is expected that in a typical mesh deployment scenario,
@@ -604,13 +615,13 @@
 
 	  <t>When receiving the OPTION_S46_PORTPARAMS option with an
 	  explicit PSID, the client MUST use this explicit PSID in
-	  configuring its softwire interface.  The OPTION_S46_PORTPARAMS
-	  option with an explicit PSID MUST be discarded if the
-	  softwire node isn't configured with a full IPv4 address
-	  (e.g. IPv4 prefix).</t>
+	  configuring its softwire interface. The
+	  OPTION_S46_PORTPARAMS option with an explicit PSID MUST be
+	  discarded if the S46 CE isn't configured with a full
+	  IPv4 address (e.g. IPv4 prefix).</t>
 
-	  <t>The OPTION_S46_PORTPARAMS option with an explicit PSID MUST be
-	  discarded if the softwire node isn't configured with a full
+	  <t>The OPTION_S46_PORTPARAMS option with an explicit PSID
+	  MUST be discarded if the S46 CE isn't configured with a full
 	  IPv4 address (e.g. IPv4 prefix).</t>
 
 	  <!--<t>On receipt of the Port
@@ -768,6 +779,10 @@
     <postamble>M - Mandatory, O - Optional, N/A - Not Applicable</postamble>
       </texttable>
 
+      <t>MAP-DHCP clients that receive container options that violate
+      any of the above rules MUST silently ignore such container
+      options.</t>
+
     </section>
     <section title="DHCPv6 Server Behavior">
       <t><xref target="RFC3315"/> Section 17.2.2
@@ -778,16 +793,16 @@
       enumerated one in its Option Request Option.</t>
 
       <t>A CE router may support several (or all) of the mechanisms
-      mentioned here. In the case where a client requests multiple
-      mechanisms in its ORO option, the server SHOULD reply with all
-      the corresponding Softwire46 Container options.</t>
-
+      mentioned here.  In the case where a client requests multiple
+      mechanisms in its ORO option, the server will reply with the
+      corresponding Softwire46 Container options for which it has
+      configuration information.</t>
     </section>
 
     <section title="DHCPv6 Client Behavior">
       <t>An S46 CE acting as DHCPv6 client will request S46
       configuration parameters from the DHCPv6 server located in the
-      IPv6 network. Such a client SHOULD include the S46 Container
+      IPv6 network. Such a client MUST include the S46 Container
       option(s) that it is configured for in its ORO in SOLICIT,
       REQUEST, RENEW, REBIND and INFORMATION-REQUEST messages.</t>
 
@@ -808,6 +823,7 @@
       for the prioritization and handling of multiple mechanisms
       simultaneously.</t>
 
+
 <!--      
       <t>DISCUSS: There are many ways of delivering IPv4 to a CE
       router. Native IPv4 with global addressing, native IPv4 with
@@ -837,12 +853,6 @@
       <t>Section 23 of <xref target="RFC3315"></xref> discusses DHCPv6-related
       security issues.</t>
 
-      <t>By successfully compromising DHCPv6 server that provisions
-      MAP configuration, the attacker can influence not only IPv6
-      configuration, but also IPv4. In that sense, this widens the
-      impact in case of successful attack on clients. This affects
-      only clients that support and attempt to use MAP.</t>
-
       <t>As with all DHCPv6-derived configuration state, it is
       possible that configuration is actually being delivered by a third
       party (Man In The Middle). As such, there is no basis on which
@@ -850,16 +860,9 @@
       bypass any security mechanisms such as IP firewalls.</t>
 
       <t>In IPv6-only networks that lack any IPv4 firewalls, a device
-      supporting MAP could be tricked to enable its IPv4 stack, thus
-      exposing itself to previously infeasible IPv4 attack
-      vectors.</t>
-
-      <t>MAP options are more complex then typical other DHCPv6
-      options. Malicious client may repeatedly request all Softwire
-      container options to induce increased server load required for
-      generating more complex responses. For a properly implemented
-      server this attack vector should not pose significant
-      problem.</t>
+      supporting MAP could be tricked into enabling its IPv4 stack and
+      direct IPv4 traffic to the attacker, thus exposing itself to
+      previously infeasible IPv4 attack vectors.</t>
 
       <t>Section 11 of <xref target="I-D.ietf-softwire-map"></xref> discusses
       security issues of the MAP mechanism.</t>
@@ -905,6 +908,10 @@
       &rfc3315;
 <!--      &rfc3633;-->
       &rfc2119;
+      &I-D.ietf-softwire-map;
+      &I-D.ietf-softwire-map-t;
+      &I-D.ietf-softwire-lw4over6;
+
     </references>
 
     <!--  SECTION 8.2:  Informative References		-->
@@ -914,9 +921,6 @@
       &rfc2131;
 <!--      &rfc5226;-->
 <!--      &rfc6335;-->
-      &I-D.ietf-softwire-map;
-      &I-D.ietf-softwire-map-t;
-      &I-D.ietf-softwire-lw4over6;
 <!--      &I-D.mdt-softwire-map-deployment;-->
 <!--      &I-D.ietf-homenet-arch;-->
 <!--      &I-D.ietf-dhc-option-guidelines;-->

---

From: Tomek Mrugalski <[email-masked]>
Date: Sat, 11 Oct 2014 21:02:35 +0200

On 10/10/14 21:32, Ted Lemon wrote:
>> This option follows behavior described in Sections 17.1.1 and
>> 18.1.1 of RFC3315. Clients can insert those options with specific
>> values as hints for the server. Depending on the server
>> configuration and policy, it may accept or ignore the hints. Client
>> MUST be able to process received values that are different than
>> the hints it sent.
> 
> What guidance would you give the client as to what hints to send?
> How would you avoid having the server do the wrong thing with hints
> based on stale data?   This is why I think the "client hints" thing
> in 3315 is a mistake.   I simply don't see how you can support this
> in any interoperable way.   Supporting it at all is not likely to do
> anything, because both sides have to support it, but if they do,
> there's no way to predict whether it will actually work, because we
A well defined protocol should leave certain aspects up to implementors.
DHCPv6 already allows lots of leeway wrt to server policy. This is in my
opinion another differentiating factor between implementations. It is
certainly reasonable to imagine a server implementation that can be
configured to provide a range for a value. If client doesn't send a
hint, a default value is sent. If client sends a hint and it is within a
range allowed by an administrator, then the server sends this requested
value. Dibbler does that for lifetime, T1, T2 and couple other
parameters. I suspect that ISC DHCP allows similar logic, as there are
min-lease-time, default-lease-time and max-lease-time parameters.

> have never said _how_ it works.   So I am against specifying it this
> way; rather, this document should forbid the client sending it, so
> that if a server that implements this mistake is used, nothing bad
> will happen.
Ooops, I read your mail too late. I just uploaded -09 couple minutes ago :(

In my opinion there's no harm done with clients sending hints. Servers
will likely ignore it, but in some specific deployments this is a
mechanism that allows fine tuning. But I suppose that won't convince
you, so I won't insist.

In the next revision we'll replace this text with the one you proposed:

  This option has no meaning when sent from client to server.  However,
  servers may take options sent by clients as a hint for what values to
  return, so clients MUST NOT send this option to servers.

Sorry I missed it with -09 update.

Tomek

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Oct 2014 08:07:34 +1300

That won't affect my "Ready" review (since my questions
have all been answered).

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Oct 2014 11:45:44 -0500

> A well defined protocol should leave certain aspects up to implementors.

Yes, a well-defined protocol _can_ leave certain aspects up to implementors, or to administrator control.   But obviously some aspects need to be well-defined, or it's not a well-defined protocol.   My objection to this feature is that (a) there is no actual use case for it, as witness the fact that in the twenty years DHCP has been around, nobody has _ever_ used it in a real-world deployment, and (b) it's so completely underspecified that it is impossible to even say specifically what it does.

I tend to agree with you that there is probably no harm in allowing this, because nobody will be able to figure out what to do with it.   However, your text spoke of it as if there was a use case for it, which I think would have been confusing to implementors, since there is no identified use case for it.   So I appreciate your willingness to specify it differently.   If you want to preserve the possibility of using this, you could change the MUST NOT in my proposed text to a SHOULD NOT, and that would then no longer prohibit using this feature if a use case were identified later on.   I would not object to this.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Oct 2014 15:36:05 -0700

Thanks for your review, Brian. Happy to hear that questions have been answered. At this point I have no objection to publishing the doc…

Jari