Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

Ian Farrer <> Thu, 04 August 2016 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01F9212D0F0 for <>; Thu, 4 Aug 2016 10:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eVcyxGFtePxX for <>; Thu, 4 Aug 2016 10:40:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E38612B02F for <>; Thu, 4 Aug 2016 10:40:16 -0700 (PDT)
Received: from ians-mbp.lan ([]) by (mrgmx001) with ESMTPSA (Nemesis) id 0M3iU5-1bDYaq3uOf-00rE7i for <>; Thu, 04 Aug 2016 19:40:13 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ian Farrer <>
In-Reply-To: <>
Date: Thu, 04 Aug 2016 19:40:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: dhcwg <>
X-Mailer: Apple Mail (2.3124)
X-Provags-ID: V03:K0:ZJwiP2jDd8dN6bEcuknqdK33NZj52COj7aXiQxFBWRmFwKl8FCX 0dCiOCEMM2utr5AOiPK880rt5L7ZLoHBEM5gCD4fuTrSC7sKvFmpQ40dz8IUzXNQtrSaRw7 IQdrLawUeg3Lbh5z9SvigMJKeDfpZasivefb9dsECajcUbisaS5wdeRApjM4917gBQJ/pa/ rRJFsF472u03sEzYVSw5w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:vsOjSPYA3mw=:fqdYKYKezyGw5faOpM3Ofg N7aMztDcH0/lG3Z36GeEz1wjpyQiXIsG8pNBQJgvJ5sIMtvG3TmIwGBHGxoOIwVop6LWqOoOJ /DqFgDPMkbR9+n8VGT3Akmof0wUaY8tFnDfH3ATSHFqdQ3JPkkoiY8QaDAtxgU0v19N9DzKqi 19X1IfTf27AWlyMt1jWn0gsBuwO7BrF+P/aaaYsFJFnhAtPI/XTTJr7JBls5SHzwqXV/Jedyg XUv8qLSn1q7tnna1p5xvDcvheaSzvdYw1munKEVtaPcAuNTdSvL/+DMxLo/n2Z1w/8BZkrL2A +21F8TYvDKWqhD9lwE293y5H9t16MYr+xQyRx6UHTdDErp3T2CqybijkjU2wYj3cE5G2OkzII P3b9TM2b3h3AwTXx7ViFcVzTlOUk+kDAOj5Hoz6QtXG8C/88y/EbXqGhEND6oe9HG6ZXShWUO thmhAH4e3p59nv08xsHO1k+UYUOQda8VkEo4/We73BMS5ZF/pvSRNNBhTeaVVy+BQ1AtFYAnF VguN+8L/vj1CsIFPVkRURgYqk6q2wFhdWxhWwMYBm7+WZCPd3unqHbVilgVB2AhTQEQKIb7EB Kshs0R8f25du7XfbdyPWeB1vJ1rJsPtcoF9GVYjxEfWihYihiCbLx7T5nBULbS4xfluYQBWRZ GCE2LNyjWTuMh+YqxgcTj9fyHcxo6G6vEy2trDFJTgVvyF9pW6lC8HRk6eiQGBUg7D1L2388M eK8qbBKyiZ/RUvwgA6I6jwbgPSufRTNz/Z/z4vLbqtHxZK6vf67KgJMDc3o1syULEom763vYH ZGIA9Qw
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Aug 2016 17:40:19 -0000


Here is my comments on rfc3315-bis-05.


Section 1.4
Paragraph 2 is a repetition of the beginning of paragraph 12

T1/T2 times and how they are selected are discussed in this section, but the
purpose of the T1/T2 timers is not described until section 17.1.4. A brief overview
of their purpose would help readers.

16.1 Para 1
The sentence:
"However, the client MAY send the message through another interface if the interface is a logical
interface without direct link attachment"
is ambiguous, suggested reword:
However, the client MAY send the message through another interface if the interface which
configuration is being requested for is a logical interface without direct link attachment  

Is this really a discussion point? The provided text for considerations regarding
the use of unicast with relays seems straightforward enough and the discussion doesn’t pose any questions.

The client includes a Reconfigure Accept option indicating whether or not...
The text here is not accurate (the option is only included if it is supported) - Suggested reword:
The client includes a Reconfigure Accept option (see Section 20.20) if the
client is willing to accept Reconfigure messages from the server. Para beginning ‘When a client had received...'
There are a number of grammatical errors in this paragraph. Suggested re-word:

When a client receives a configuration option in an earlier Reply,
then sends a Renew, Rebind or Information-Request and the requested
option is not present in the Reply, the client MUST stop using
the previously received configuration information.  In other words, the client
should behave as if it never received this configuration option and return
to the relevant default state.  If there is no viable way to stop using the received configuration 
information, the values received/configured from the option MAY persist
if there are no other sources for that data and they have no external impact.
For example, a client that previously received a Client FQDN option and
used it to set up its hostname is allowed to continue using it if
there is no reasonable way for a host to unset its hostname and it
has no external impact.  As a counter example, a client that previously
received an NTP server address from the DHCP server and does not
receive it any more, MUST stop using the configured NTP server IPv6
address.  The client SHOULD be open to other sources of the same
configuration information.  This behavior does not apply to any IA
containers, as their processing is described in detail in other parts
of this document.

* Suggest also that the 'MUST stop using' is replaced with SHOULD, as the
next paragraph describes an exception to the MUST requirement.
* Also, it would be worth extending this to say that if a requested option
is received that has an updated value, then use of the previous value should be
discontinued and replaced with the new value.

17.2 Para 2
s/server sends Advertise message/server sends an Advertise message/

17.2.1 Para 6
"Sending this option back to the client may useful using the server selection
Current text is unclear, propose:
Sending this option back to the client may be useful for the server selection

17.2.2 Para 6
The term 'prefixes on included addresses' is used (twice). Suggest 'prefixes of'
is used instead.

17.2.9 Para 6
"IA_IA" is listed here. Assume IA_TA was meant.

17.2.11 Para 2
Describes the server including an ORO option to say what is changed/added, but
there is no corresponding text in 17.1.11 saying how the client should use
a received ORO in a reconf. message. (I see Bernie got this one as well)

s/If not addresses/if no addresses/

19 & 19.2
Both sections describe that RFC3315 delayed authentication is obsolete. Is the 
repetition necessary?